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PREFACE 


This chapter was written assuming the user of OS/360 has coded a 
program and faced with the task of debugging the program using the 
ABEND hex dump (ABDUMP). Areas such as System Control Flow, 
RB Queues and the trace area will be explained and explored as to 
their use in debugging. Other sections of this chapter deal with 
evaluating I/O error messages and status of DASD data sets. This 
chapter will hopefully provide all the diagnostic aids and supporting 
literature necessary to evaluate OS/860 debugging facilities in the 


Primary Control Program (PCP). — 


This document assumes that the reader is a programmer who has 
a a general knowledge of OS/360 logic flow. A recommended | 
| prerequisite to provide this general system knowledge is the IBM 

Operating System/360 Concepts and Facilities manual C28-6535, 

or Part 1 of the IBM publication; "Introduction to Control Program 
Logic," 228-6605, At specified points within the document it is 
recommended that Appendix B of the IBM Messages and Completion 
Codes Manual C28-6608, be read to supplement this manual. 
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i. INTRODUCTION 


Prior to going in and examining the different facets of the ABEND 
dump it is necessary to understand the system control flow of the OS/360 


control program, This understanding is essential in order to comprehend 
and evaluate the full ABDUMP. 


Whenever possible, actual dump examples have been included to 
Supplement the text. However, due to size limitations it is impossible 


to include examples in all areas. For this reason it is suggested that 


the reader supplement the text using his or her own ABDUMP, 
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SYSTEM CONTROL FLOW 


Task Control Block (Pe) and its associated 1 request blocks BB B) 


1. What is a TCB? 


The task control block is the operating system's way of 
keeping, in one location, pointers to all pertinent information 
about the job step and consequently the task that the job 

‘scheduler has scheduled, In the primary control program 
(PCP) there is only one TCB in the system. It is located 

in the nucleus and used by all programs that reside in the 

problem program as shown in Figures 1a and b, 


J Core Storage >| 
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Job 


scheduler 
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a TCB associated with job scheduler 
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b. Reinitialized TCB associated with problem program. 


Figure 1 
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This one TCB is reinitialized every time the job scheduler 
completes its scheduling of a job step and control is given to 
the problem program. A similar action occurs when the problem 
program completes its function and specifies the RETURN macro. 


co What type of control information is kept in the TCB? 


~The TCB primarily contains pointers to other system 
blocks imbedded in the control program nucleus. For in- 
Stance, one can determine what I/O devices have been > 
allovcted to this job step by locating the Task I/O table (TIOT); 
which data sets are open by checking the DEB list; determine 
the end of the nucleus by looking in the main storage supervisor's 
boundary box. All of these system created tables and control _ 
blocks are pointed to by the TCB. How each of these fields 
are used as diagnostic aids will be covered later. 


3. Wnatis a Request Block (RB) and why is it needed? 


‘It is very possible that all the routines for any one problem ~ 
. program or job scheduler will not be brought into core with = 
the initial load module. The use of the LINK, XCTL, ATTACH and | 
- LOAD mocro used the OPEN routine to dynamically bring in 
the access routines, is a godexample of this. This dynamic 
loading capability forces the control program to add a control 
block, in addition to the TCB, called a request block (RB). 
This request block retains control information at the load 
module level. One of these RB's is created by the control 
program whenever a dynamic request to fetch a load module 
for execution is given. The RB is located in problem core as : 
indicated in Figure 2a. | | | _ 
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b. RB created for l6ad module B 
Figure 2 


Figure 2b shows the relative position of a second RB 
which was created when load module A issues a LINK 
macro. The control program nucleus responded to the 
LINK macro by fetching load module B into core and creating 
an RB to retain control information about this module. 


4, ' What kind of control information is kept in an RB? 


The content of the RB is an important element of the 
‘debugging procedure. Its content and size vary depending 
on what type of RBitis. If we assume that the RB is for 
a load module that was LINKed to, as in Figure 2, it 
would be 32 bytes in size and would contain such things as 
the member name or alias that this load module was 
fetched by; the size of this load module and its RB; and the 
PSW as it existed when control was passed to the nucleus the 
last time. How each of these fields are used to aid in 
' ,debugging is covered later. 
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 §, How does the System know which load module to give 


control to? ; 


‘The question is very valid. Prior to this, the discussion 
centered around the TCB and the RB, but not how the two are 
interconnected. This is a good point to introduce the two 
request block queues that the system uses to control what | 
load module gets control of CPU time. They are called 
the Active RB Queue and the Load List. . The next section 
describes their actions. -_ 


RB Queues 


As indicated earlier, there are two RB queues that the 
System creates and maintains. These queues provide the 
means by which the primary control program keeps track 
of and allocateS two very important resources ~ CPU time 
and load modules (programs) currently in core. 


1. Active RB Queue 


Prior to developing the active RB queue, it is necessary 
to explain the TCB - RB relationship. To clarify this _ 
subject, it is convenient to initially assume that; the:job 
. scheduler has been in core, read the job control language 
(JCL) defining the job step; allocated the I/O devices and . 
requested the control program, via an XCTL macro, to 
fetch load module A, The control program nucleus has 
created an RB for load module A, fetched the module 
into core storage and given control of CPU to module A. 
At this point in time, core storage contains the nucleus, 
load module A, and its RB in lower core. With the exception 
ofa system table in upper core, the rest of core is free 
for allocation as indicated in Figure 3. 


Load module A was defined to the system via an EXEC 
PGM=A card in the input job stream. It should be noted 
that the system always places the RB, associated with load 
module (program A), on the first doubleword boundary 
outside the nucleus (assuming no storage protect). With 
storage protect the first RB is placed on the first 2048 
byte boundary outside the nucleus. The load module A 

is contiguous with the request block. | 
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Nucleus Load — _ | ystem 
Module A Free Core Table 
(Program A)| = (TIOT) 

| Figure 3 


Logically, the TCB and RB are linked up as shown in 
Figure 4, The TCB always contains a pointer to the RB 
whose associated load module has control. In our example, 
only one load module is in core, so the address of its request 
block is placed in the TCB. This pointer in the first RB 
contains a pointer to either a previous RB or the TCR. In 
our example no previous RB's exist, so this field does point 


back to the TCB. Additional fields, such as the member name> 


and entry point are shown to reflect some of the control 
information that is retained in the request block. 
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RB-A 
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Figure 4 


The linking of the TCB and RB together creates the . 
beginning of the active RB queue. Bydeéfinition this is 

a gueue of request blocks that keep track of active 

load modules Ni saan aaa ia 
or ATT ACHed. 


_ ‘To elaborate on this, one must expand the previous 
example. Assume that program A now LINKs to program 
B. The LINK macro, when assembled, degenerates into 
an SVC 6 which causes an interrupt and gives control _ 
_to the nucleus. Figure 5 shows the updating of the con- 
trol block pointers that takes place prior to giving control 
to program B. 


TCB 


Ct top RB = 


Program B 


TURN 


‘er . . 


At time(2 When Program B gains senieel of CPU, the 


active RB queue is connected as described below. 

The top RB pointer in the TCB points to the RB - B 

(whose program is in control). The link field in 

RB - B points back to RB - A, whose associated 

program will regain control when Program B com- 
pletes. The link field in RB ~ A points to the TCB because ° 


‘it is the first RB on the queue. A Snapshot of core at 
time(2 would look like Figure 6. | 
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Figure 6 
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How does the nucleus know where to return control to 
in Program A? 


Referring to timed 1), Figure 5, when the SVC 6 causes 
an SVC interrupt, the nucleus retains the SVC old | 
PSW in the request block for program A. This 8 

byte field in RB ~ A, called RESUME PSW, will 
therefore contain all pertinent information about 
Program A's resumption point. The nucleus, 

between times 3 and(4) performs an LPSW 

instruction specifying the Resume PSW field of RB ~ A 
and Program A regains control at the proper point. 


2, The Load List 


The load list, by definition, is a queue of request blocks that 

keeps track of load modules that have been fetched into core via © 

the LOAD macro. These programs or load modules will remain 

dn core until either a DELETE macro is issued for them, or job 

step termination occurs. Modules that are LOADed and their 

associated RB's, are fetched into the upper end of core : _ 
Storage. As you recall, modules that are XCTLed,ATT ACHed, Nw 
or LiNKed to are fetched into the lower end of core, This tends 

to keep contiguous free core between them as shown in Figure 7. 


Program A| Program B | Free} Program {TIOT 
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(LOADedq) 
Figure 7 


The linking of the TCB and the RB's on the load list differ slightly from 
the active RB queue. To understand the need for a different type of 
queue, one must understand the logic behind the LOAD and DELETE 
macro, Upon issuing the LOAD macro, the nucleus fetches the 
yequested load module, creates an RB, and initializes a load list as 
indicated in Figure 8. _ 
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Figure 8 


The nucleus then passes back to the issuer, in Register 0, the entry 

point to the requested routine. At this point the issuer of the LOAD 
macro regains control and may, at will, branch to this loaded routine, 
using the entry point passed to him. An important fact is that the nucleus 
does not know when the user is eperanng in the loaded routine ane there- 
fore cannot delete it. 
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The system must wait for a DELETE macro to be issued by the user 
or step termination to take place before freeing up the RB and core 
associated with a LOADed program. 
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_ Upon issuing of the DELETE. macro, the nucleus gains control, 
via an SVC interrupt, and searches the Load List for the specified 
load module. It uses the two pointers of the extended RB, shown 
in Figure 8, to perform this search and find the requested load 
module. The SUCCEEDING pointer contains zeros. The 
PRECEEDING pointer of the RB points to the previous RB on the 
Load List. This field in the first RB on the Load List points 
back to the Load List field in the TCB. The purpose of the two 
. pointers is evident when one considers that the system must 
be able to DELETE load modules whose RB's are in the middle of | 
the list. Both pointers are necessary to delete the RB and link 
both ends of the load list back together again. 


a Does the Primary Control Program use the LOAD macro 
to bring in any of its routines? 


Yes, a good example of the use of the LOAD macro is 

its use by the OPEN routine. Access method routines 
are brought into core at OPEN time via the LOAD macro. 
At CLOSE time the DELETE macro purges these Eouree 
if they are not in use. 


ob How could these access method routines be in use? 


When initially LOADed at OPEN time these modules are 

_ brought into core and a one (1) is placed in the USE 
COUNT field of the RBs associated with these modules. 
If a second data set isOPENed, specifying the same access 
method or requesting the same load modules, the control 
program simply increments the USE COUNT in the RB, 
passes back the modules entrypoint in Register O and 
does not fetch another copy. At CLOSE time the DELETE 
macro decrements the USE COUNT in the RB and only 
if it goes to zero, purges the module and frees up the core. 
Otherwise, the module would remain in and be en 
the CLOSE of the second data set. 
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Cc. . System interaction between the two queues 


_ The Active RB Queue and the Load List make up the 
_ contents directory for the sequential system. Depending on - 
which macro is given, XCTL, ATTACH, LINK or LOAD, 
the system reacts differently as to the queues it checks 
before it fetches another load module. Let's take a few 
examples to point out the differences. 


1. Figure 9 shows the resulting active RB queue after ; 
Program B LINKs to Program C. | 


Figure 9 


Upon return from Program C, its RB and associated 

load module is purgeeland the core freed up. The | 
Same action takes place upon the return from Program i 
Bto A. At that point the Active RB Queue looks like 

Figure 10. | 


oT 6u 


+ Me aly m6 


{ts ee | 


Figure 10. 


If at this point Program A LINKed to B again, the following. 
sequence takes place. The Load List is searched for B; if not 
found, a new copy of load module B is brought into core; an RB 
created; and the Active RB Queue updated accordingly. Control 

. then passes to B. If load module B has an RB queued on the load 

_list, then the primary control program (PCP) determines if the 

- module is usable. If itis, the same RB that is queued on the load 
list, is queued on the Active RB Queue and control is given to load 
module B as shown in Figure 11. The control program determines 
whether a load module is usable or not by evaluating the STATUS 
field of the associated RB. How this STATUS field is set will be 
expanded upon later when RB types are covered. 


P99 


 TCB 

\ load list : | 
a an Ber, | |; RB-B 
| ‘). RBA. 


¢ | ——- Figure 11 


Zi pe 


2. 


How does the issuing of an XCTL macro differ from 


| the LINK macro we just talked about? 


XCTL's effect on the system is best Scie by 


- referring back to the in core situation indicated 


in Figure 6. Basically Program A LINKed to 
Program B. Let's assume that the programmer 
wished to execute Program C and then RETURN to 
Program A without going back to Program B. 
XCTL provides this capability by logically over- 


laying Program B with Program C. Upon returning | 
- from Program C processing is resumed in Program A. 


At the point when the XCTL macro is issued in 
Program B the Syctem blocks are queued as shown 
in Figure 12. | 


SAVE SAVE 

PROGRAM A PROGRAM B 

LINK B __ 

RETURN XCTLC 
Figure 12 
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The following events occur in the nucleus upon issuance of 
the XCTL macro. It, like LINK, degenerates into an SVC 
interrupt allowing the nucleus or control program to gain 
control. The first function performed is to search the Load 
List for load module C. If found and usable, RB- Cis 
queued on the Active RB Queue; RB - Band load module 
B are purged and its core is freed; and control is given to 


If load module C is not on the load list, program B and its 
RB is purged leaving program A and its RB as the only routine 
inuser core. The nucleus then fetches module C, creates 3 
an RB, and chains it on to the Active RB Queue as indicated in 

Figure 13. | | | | 


7 RB-C : 


SAVE | 3 SAVE 
PROGRAM A PROGRAM C 
RETURN RETURN 


Figure 13 
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| ' Figure 14 reflects a snap. shot of core as it exists while © 
| executing een C. | 


‘|TCRRB-Al |RB-C Pept tS | 


‘Nucleus | . Program A ‘Program C Free Core TIOT . 


Figure 14, 


The important thing to note is when an XCTL macro is 
issued another level of request block is notcreated as is with 
_ a LINK or ATTACH macro. 


3, How is an ATTACH handled on the primary control program ? 


co. The ATTACH macro normally initiates a section of the : 
overall program, called a subtask, that can be processed | 
in parallel with the main program asychronously. | 
However, in the primary control program only one task analael | 
block exists. It is impossible to dynamically create | 

another TCB, and impossible to process a subBask 
asychronously. The next best thing is to allow the use of 

the ATTACH macro, when looking ahead to the multitask 

operating system, and to perform the ATTACHed routine | 
serially. This is what the primary control program does. : 
‘It performs the ATTACHed routine much like a LINK with | 
a few exceptions. The ATTACH macro allows specification | 
of an exit routine (EXTR parameter) and the posting of an | 
event control block upon completion of the ATTACHed : 
routine. Both the exit routine and ECB are located within 
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the ATTACHing load module. These features are handled 
by placing additional request blocks on the active RB 
Queue as shown in Figure 15. 
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Figure 15 


In the example shown (Figure 15), program A 
ATTACHes program B specifying an exit routine to enter 
upon completion of program B, and an event control 

block within program A to be posted upon completion of B. 
The system makes the normal search of the Load List 
as the LINK routine did. If the requested program is not 
found, it is fetched into core and the Active RB Queue is 
updated as shown in Figure 15. Program B gains control 
of CPU. Upon completion of program B, the ATTACH 
routine in the nucleus would receive control and POST 
the event control block indicated. Control would then be 
given to the EXTR routine. Upon RETURN from the EXTR 


routine control again passes to program A to resume pro- | od 
cessing. | 


. summary of Sequential Program Execution 


Program A was fetched into core as the result of the 
Job Scheduler reading an EXEC PGM=A control card. 
The logical sequence of control flow that occurs, starting 
at IPL time, is something like the following: 


a. By depressing the IPL key on the console and 
Specifying the SYSRES device in the load address 
keys, the computing system reads in an IPL 
Bootstrap record. This Bootstrap record, 

'. consisting of a chain of channel commands, reads 

in the IPL PROGRAM LOADER, At this point 
the load light on the console goes out and control 
is passed to this IPL Program Loader. Its 
Tunction is to read in the nucleus plus the nucleus 
initialization program (NIP). NIP and the nucleus 
are combined as one load module and written on 
the system residence device at system generation. | : 
time. | . 
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‘Once the nucleus and NIP are in core, NIP gains 


control and proceeds to initialize the nucleus. Just 
prior to NIP's completion the Active RB Queue would ~ 
look similar Lo pare 16. ° 


Nucleus: 
Initializations 
Program 


ACTL-IEFK1 


Figure 16 


NIP would then logically XCTL to the master — 


scheduler function of an XCTL, NIP will be 


overlayed by the master scheduler. The master 
scheduler would then issue the READY message-and 
wait for the SET DATE command to be entered at 

the console. Upon receiving this command from the 
operator, the system will then issue the automatic 
START RDR, START WTR commands and wait on 
changes to these commands or/and a START command. 
The master scheduler XCTL's to the reader interpreter. 
At this point the system blocks logically looks like 
Figure 17 
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Interpreter 


ACTL... 


Figure 17 


The Reader Interpreter opens the system input and output 

devices and proceeds to read the input stream. It then a 
creates the system tables necessary for job initiation and oN? 
I/O device allocation. The Reader/Interpreter will 

continue to read the input stream and create tables until 

DD* card, null card or another JOB card is read 

Upon recognizing one of these, it XCTL's to the 

Initiator. System blocks at this point in the job 

step initilation cycle logically looks like Figure 18. 


TOB . RB-INT_ 


D. RB Types 
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The Initiators primary function is to allocate I/O devices 


_ to the job step and obtain DASD space. Once the 


allocation of devices is complete the Initiator builds 
a task I/O table (TIOT) which lists the ddname and a 
pointer to the assi¢ed device or devices for each data 
Set of this job step. This TIOT table is placed in upper 
core and is the system sable that has been referred to 
On previous core snapshots, By using this table, one 
can determine what devices the job scheduler has © 
assigned to user data sets. The Initiator then XCTL's 
to the load module specified in. the EXEC card, In our 
example it was program A. 


Upon completion of the problem program (A in our 

example) the RETURN macro will return control to the 
nucleus and it, in turn, will XCTL to the termination section 
of the initiator. This phase of the job scheduler takes care 
of the disposition of the data sets and frees up the proper | 
I/O devices. It would then initiate the next job step 

or XCTL to the Reader Interpreter to read in the next 

JCL. The whole sequence starts again. 


Logically, this past sequence of events is how the system 
blocks are used both by the job scheduler and the 


problem program. Due to the different means of packaging 
' the job scheduler the names of the modules and the number 


of XCTL's will vary,. The sequence shown is for logic ~ 
purposes only. Refer to the Job Management PLM for actual - 


module names and number of loads. 


Up to this ,oint the assumption has been that there is one type of 
request block, 
The RB type, its size and the fields:'usea within it varies depending on 
the routine or load module it is associated with. To be able to analyze 
the RB queues, one must be able to recognize the different types and 
and know their function. Figure 19 shows the fields and core size required 

' py the six different types of request blocks. | 


In reality there are six different types of request blocks. 
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LRB = Loaded Request Block 

LPRB - Loaded Program Request Block 
PRB - Program Request Block 

IRB - Interrupt Request Block | 

SIRB + Supervisor Interrupt Request Block 
SVRB - Supervisor Request Block 
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Program Request Block (PRB) 


The system jaitially starts out with one PRB 
and it is asscCiated with NIP as indicated in 


an earlier section. This RBis the most common 


and primarily the one described in the previous 
examples. PRB's are created by the nucleus when- 
ever an XCTL, ATTACH, or LINK macro is © 
issued. This request block is 32 bytes in size © 


-and always contiguous to the load module that it. 


is associated with. 


Supervisor Request Block VRE) 


The supervisor or nucleus wiien it gains control | 
of CPU executes its code in two basic operational 
modes. The, first operational mode is when an 
interrupt occurs, the supervisor executes a 


routine which performs some function, and 


returns control to the problem program. In 


‘this mode the supervisor disables all interrupts 
except the machine check. Because there is no. 


possibility of interruption, no request block 
is required to retain interruption status. The | 
second mode of operation occurs when the code that 


the supervisor is executing allows interrupts or 
operates enabled. This mode, therefore, requires 


a request block to retain status and save registers. | 
in case an interruption occurs. This request | 
block is called a supervisor request block (SVRB). : 
It is created for, and associated with, SVC 

interrupt routines. An SVRB is dynamically 


created by the nucleus whenever the supervisor 


determines the requested SVC routine operates 
enabled. Free core is obtained at the upper end of 
core to build there SVRBs. 


a. Do all SVC routines operate with interrupts | 
enabled? | | | 


No, all SVC routines are broken down into | 
types I through IV as described below. | 
Type I - These routines are always resident : ! 
and operate disabled. 

Type Il - These routines are also resident; 
but are partially enabled and reenterable. = |. 
Type UI - These routines are non-resident 
and reentrant. They are brought into the | 
1024 byte SVC transient area for execution 
from the Ce SVCLIB data set. 


‘Interrupt Request Block (IRB) 


is such that at certain points in the processing 


) 
Type IV - These are multi-phase type ITI routines. 7 


They are too large to be brought into the transient = ~~ 


. area at one time and must be brought in phases. . 


Control is passed from phase to pueee via an 


XCTL macro. 


SVRB's are, therefore, created for control of 
the type II, III, and IV SVC routines. Appendix 


A contains a list of the SVC's and their type 
classification. 


The processing environment of the operating system _ 


cycle functions are defined to be processed if an 
asynchronous or unpredictable event occurs. 

The IRB is used to control these user and system 
asychronous exit routines. A good example 

of its use is when a timer routine is specified 

in the STIMER macro. This user routine, located 
in problem core, is given control when the ! 
specified time internal ends. Because onecannot- \/! 
predict when this internal will end, the STIMER 

SVC routine creates, by a GETMAIN requesting © 

upper core, an IRBto control this user timer 


’ - routine. When the interval times out and 


causes an external interrupt, the supervisor 


initializes the IRB, chains it onto the Active 


Queue and gives control to the user routine. 
The Active RB Queue at this time would look like 
Figure 20. 
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User Timer 
routine 


RETURN 
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gupervisor Interrupt Request Block (SIRB) 


‘The function of an SIRBis similar to an IRB only 

an SIRB is associated only with the IBM supplied | 
system I/O error routines. There are two additional. 
features that are unique to an SIRB, There is only 

one SIRB and its associated routine operates outoza — 
400 byte transient area in the nucleus. Its associated 
routines are fetched from the SYS1. SVCLIB data set. 


’. Loaded Program. Request Block (LPRB) 


_ These request blocks are used to control programs 
_ that are fetched into core as the result of the LOAD 
macro. An LPRBis always chained onto the Load 
List via use of the SUCCEEDing and PRECEEDing 
pointers which are unique to RB's associated with 
LOADed programs. An LPRB may also appear on 
the Active RB Queue as the result of an ATTACH, 
XCTL, or LINK being issued for its associated load 
module. In this case, the RBis maintained on both 
queues simultaneously through two different sets of 
pointers as indicated in’ appendix A, Figure 1. The 
LPRB is physically located adjacent to its LOADed 
routine and are allocated in core storage starting at _ 
the high end and working toward the middle. 


Loaded Request Block (LRB) 


This request block is a shortened form of an LPRB 

and used to control LOADed modules that have the 

only loadable (OL) attribute. This means that once 
loaded, this routine may be entered only by a branch. 

It is invalid to ATTACH, LINK, or XCTL to modules - 
with this "OL" attribute. An LRB will be chained onto 
the Load List and will never be found on the Active RB 
@ueue. It will be contiguous with its load module similar 
to the LPRB. A load module obtains this "only loadable" 
attribute at linkage editor time via the programmer 
specifying the OL subparameter in the PARM field of the 
EXEC control card. The most common reason for a 
programmer to specify this attribute is that he has not 
followed the linkage conventions required by the ATTACH, 
XCTL and LINK. Both the LRB and LPRB remain on 

the Load List until their routines are deleted as described 
in section B-3. 
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- TCB and RB Fields 


This section explains the TCB and RB fields using the 


_ formated output of the ABDUMP., 


1, The TCBABDUMP format is shown in Figure 21° 


-- CB 000180 RB  O1F83C PIE 000000 
DEB OIF7BC TIOT O1FF5C CMP .0C6000 
TRN 00000000 , 


“MSS 00003CB8 PK/FLGS 00910400 FLGS/LDP 00000000 | 


ELS o1rss0 JLB O1FEEO JSE ~ 00000000. 
ID/FSA 0401FFB4_TCB 000000 TME 003CCC. 
Figure 28°2) 


The son owing is an explanation of TCB fields that are helpful 
in aueugging problem programs. All TCB fields are dumped. 
in hexadecimal. The first 6 hex digits on line 1 of Figure 21 
reflect the location of the TCB. 


a. RB - This 4 byte field contains a pointer to the 
top request block on the Active RB Queue. 
b. PIE - This 4 byte field contains a pointer to the 


Program Interrupt Element (PIE) if a SPIE 
macro has been issued by the problem program. 
7 Otherwise it contains zeros. A SPIE macro‘ allows 
| ‘the programmer to mecify an exit routine to be 
entered when specified program interruptions 
occur. The control program creates a 32 byte 
Program Interrupt Element to accomplish this 
function. 
Cy DEB - This field contains a 4 byte pointer.to the 
Data Extent Blocks created for the OPENED data 
sets of the current job step. By using this field in 
conjunction with the second word in the chained 
_DEB's one can determine which data sets have 
been opened. ‘This area will be expanded later on. 
d. TIOT - This 4 byte pointer contains the location 
of the Task I/O Table. From this table, one may 
determine which I/O device and associated unit © 
' control block (UCB) has been allocated to a specific 
data set. 
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CMP - This is a 4 byte field which contains 


‘the task completion code in hexadecimal. Only 


the right three bytes are used and these are 


Split in two. The left three hex digits represent 


a completion code supplied by the problem | | Lan 
program through a subparameter of an ABEND 
macro-instruction. 
TRN - A 4 byte field used by TESTRAN contains 
the address of the Control Core table for controlling 
testing in a task. . 
Mss - A 4 byte field containing a pointer to the 
Main Storage Supervisor's boundary box. Useful 
in determining core size and resident control 
program size. 
PK/FLGS - The first two hex digits (1 byte) are 
the contents of the protection key field. When © 
protection is implemented this field will contain | 


the assigned protect key for the problem program. 


The last six hex digits are the first three bytes of 
the flag field. Interpretation of these flags will 
help determine how ABEND was entered. 
FLGS/LDP - This 4 byte field will be used later 
under Option 2 and 4 environments for additional 


flags and indicating dispatching priority. 


LLS - A 6 digit hex address of the most recently 

added request block on the Load List. This is the 

Load List pointer that was explained in an earlier & y 

section. Total field length is 4 bytes. 

JLB - A 6 digit nex pointer to the address of the 

DCB for the job library. If a JOBLIB DD card 

Was not specified for this job, this field will contain - 

zeros. Total field length is 4 bytes. 

JOB - This 4 byte field contains a pointer to the 

Inactive Program List explained in an earlier 

section. 

ID/FSA - This is an 8 digit hex number. The 

first two digits (1 byte) are always 04 in the PCP, 

The last six digits (3 bytes) are the starting 

address of the system supplied first problem 

program Save area. 

TCB - This is a 4 byte hex field which will contain 

zeros. Later, under option 2 and 4, this field 

will be used to chain the TCB's together to form — 

the ready/wait queue. 

TME - A 4 byte field which contains a pointer. | 

to the timer element. This field is not printed if . | 
| 
| 
| 


the computing system does not contain the timer 
option at system generation. 
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. Itis important to note that the unformatted TCB _ 
within the dump has additional fields that are not — 
| | formatted by ABDUMP. Use the Introduction to 
ra | : Control Program Logic Manual 228-6605 as a 
| ~ guide to peSunes an unformatted TCB. 
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The RB ABDUMP format is shown in aoe DOs 
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- me: 


A001 Q0SAAS NM.“ LAST ~—SZ/STAB 005600C0 
USE/EP 00005AC8 PSW FFO5000D 80005BFC  t™*” 
io 000000 WT/LNK 00000264 UB ~ — 005D58 


Figure 22 


AOQQ1 ‘on the first line indicates this is the request block 
that is chained to the TCB, (Lowest RB on the Active 
RB Queue). The next 6 hex digits indicates the location 

of the request block being formatted. 

a. NM - This is an 8 character name or program 

identifier field of the request block. The contents 

of this field will vary depending on the type of RB. 
‘A program request block (PRB) will contain the 
member name by which the program was fetched. - 
A supervisor request block (SVRB) for a type II | 
and IV SVC routine will contain the signed decimal 

SVC code of the routine associated with this SVRB, q 
For example, ABEND is a type IV SVC routine. 

Its associated SVRB will contain a OIC in this field. 


This is the signed decimal number for the ABEND 


sgl ra ~~ eno 
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b. SZ/STAB - This is an eight hex digit printout. The 
first four hex digits give the size of the RB plus its 
associated load module in hex, in doublewords. 

In Figure 22 the size field contains nex 0056. This 
represents an RB plus load: module size of 688 bytes in 
decimal. This size field is used for this purpose 

only in loaded program request blocks (LPRB), loaded 
request blocks (LRB), or program request blocks 
(PRB). In SVRB's, IRB's, and SIRB's the size field 
indicates the size of the request blocks only. The 

last four hex digits are a set of status indicator 
denoting the RB type, active/inactive status, etc. 


see Appendix A figure 2 and 38 for a further break- 
down of this field. 


ee ee 
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USE/EP - This is an eight digit hex printout. 


- The first 2 hex digits are the use count. This 


field contains a count of the number of LOAD 
requests for a program. As explained earlier, the 
use count applies only to LRB's and LPRB's. The | 
next 6 hex digits of this printout contain the entry 


_ point (EP) for the program or load module associated 


with the RB. 

PSW - A 16 hex digit representation of the resume 
program status word (PSW). This field contains 
the last old PSW from either an I/O interrupt, or 
a type I, I, IV SVC interrupt. 

Q-AS hex digit representation of the secondary 


queuing field. This field contains one of the following: 


1. For interruption request blocks (IRB), the 

address of a 12- or 16-byte request element. 

Qs For program request blocks (PRB) and loaded © 
program request blocks (LPRB), the address 
of a loaded program request block, which 
describes an entry point identified by an 
IDENTIFY macro-instruction. 


ar For a supervisor request block (SVRB) for 
| a type Il or IV SVC routine, system information. 


WT/LNK - The first two hex digits are the wait count. 
This is the number of WAITS which must be satisfied 
before this RB and its associated program may be 


' dispatched. The last six digits are a pointer to the 


next RB on the Active RB Queue. A pointer to the 
TCB will reside in this field for the lowest RB (A001). 
UB-A three byte field calculated by ABDUMP to 


indicate the upper bounds (hex address) of the load 


module associated with a PRB, LRB and LPRB. 

REGS O-7 

REGS 8-10 - These fields represent the contents of 
the registers and are associated only with super- — 
visor request blocks (SVRB) and Interrupt request 
blocks (IRB). This field is uSed like a users save 
area for the supervisor routines associated with these 
RB's. (These fields are not shown in Figure 22). 
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_ At this point one should have a good knowledge of the system control 
flow. This knowledge should be supplemented by locating the various 
system queues and control blocks on an actual ABDUMP output. 
This would also be a good point to read Appendix B, of the Control 
Program Messages and Completion Codes Manual C28-6608, which 
explains the fields within ABDUMP. It is recommended that the 
reader place Appendix B at the back of this chapter to insure the 
ABDUMP writeup and explanation is located in one place. 


30 


é mt ABDUMP 


A. 


User or System Problem? 


Determining whether the problem is a system deficiency or a 
problem program error is the first step in any debugging 
process. In using the dump, one must first determine the type 
of error and second what prograr was in control when the error. 


occurred. 


Ls Determining the type of error 


To determine the type of error, the most positive clue is 

the completion code. One can quickly distinguish whether 

the user or PCP system supplied the completion code. 

The system prints out in decimal the user supplied completion 

code preceded by USER=notation. System supplied completion 

codes are preceded by SYSTEM=notation and printed in. 

hexadecimal. A system completion code does not always 

mean that the user is not at fault because a user program 

can indirectly cause the ABDUMP. Therefore, the answer . 
to whether it is a user or system problem cannot be arrived 

at until the Active RB Queue is investigated. 


2s RB Queue Evaluation 


The highest priority KB (the top of the Active RB Queue), 4 
will always be an SVRB for the SVC routine 051, which | 
. is ABDUMP, This SVC routine formats and prints the 
dump.. The next RB on the queue below ABDUMP is an 
SVRB for the SVC routine 013, whichis ABEND, This 
SVC routine gains control whenever the system or user 
issues the ABEND macro. All RB's in the chain preceding 
these will be either the users, and/or those of data manage- 
ment (OPEN, CLOSE, etc.), other Type II, IN, IV SVC 
routines, or the job scheduler. A typical Active RB Queue 
at ABDUMP time is shown in Figure 23. 


~AOQO1 AQQ2 A003 A004 
NMPGMA NMPGMB NMSVC-401C NMSVC-105A 


PRB : PRB SVRB SVRB 
TCB ARB *RB fep 
Figure 23 _ , we 
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It is easily determined, by looking at the NM field in 
the RB, whether the users problem program was in 
control or not. In Figure 23, assume the load module 
_ called PGMB was in control at the time ABEND was 
‘Called. PGMB may. have issued the ABEND macro, in , 
_ which case a users completion code would appear on the -. . 
‘dump. A second possibility is that PGMB may have - 
caused the system to issue an ABEND (i.e. - causing 
a program check). In the latter case, a system completion 
_ code would be printed on the dump but the problem was 
caused by the users program. . 


Naming Conventions _ 


The programmer should know his load module names which 
appear in the NM field of the RB. However, the NM field 

for SVRB's and PRB's associated with system components 

iS not quite so easily interpreted. Itis, therefore, 
appropriate at this time to cover the naming conventions 

for system components and non-resident SVC routines. 

All system component load module names have the first three 
characters coded. The prefixes are listed in Appendix A under 
Operating System/360 Naming Conventions. If for example, 
a PRB was on the Active RB Queue for a job scheduler 
module, the NM field of the PRB would contain IEF Fzzzzz; 
where zzz2zz represents the rest of the module name uueauer 
within the job scheduler. 


The conventions for naming non-resident or transient SVC 
routines adds additional conventions to the three unique 
characters, IGC, which denotes transient SVC routines. 
The following conventions are used: 


Type If - IGCOOnnn; nnn is the signed decimal 
number of the SVC routine. This name must 
be the name of a member of a partitioned data 
set (SYS1.SVCLIB). 


- Type IV - IGCssnnn; nnn is the signed decimal 
number of the SVC routine, and ss is the number of 
the load module minus one, e.g., ss is Ol for the 
second load module of the routine. This name 

‘must be the name of a member of a partitioned 
data set (SYS1. SVCLIB). 


a35=¢, 


fc a = atin 


In Figure 23 the load module member name, 
on the data set SYS1.SVCLIB, is IGC401C (in 
extended BCD). The system places only the 
last four characters, 4OQ1C, in the NM field 
of the associated SVRB. This is possible 
because the system knows that all SVC type 
III and IV routines are preceded by IGCO. 
SVRB's for Type IIT SVC routines (enabled and 
resident) do not have any meaningful. names 
in the NM field because the system does not 
require a module name, it simply branches 
to the appropriate resident routine. 


At this point, one should be able to determine via 

_ the completion code and evaluation of the Active RB | 
Queue, who issued the ABEND, and what load module 
was in control at ABEND time. In addition one should 
be able to determine, by evaluating the STATUS and 
NM fields, of the controlling RB, that the load module 
was either a system component or user program. 


User Problem 


The assumption at this point is that the user has determined 
that the problem is either within his program or caused by 


some function performed in his program. To cover the first 


case, assume the user issued the ABEND. He should be able 
to localize the trouble using the completion code, which he 


issued in an ABEND macro instruction, and tie this back to 


his:source listing. Next step would be to locate his program 
in core to analyze the present status of the program. 


1. User Program Location 


How dol find my program in core? The location of any 
program may be calculated using information in the | 
associated request block. If the entry point of a particular 
program is the first instruction in that program, then the 
program boundary is given to the user via the EP field and 
upper bound (UP) field in the RB. If, as in the case ofa 
FORTRAN written module, the entry point is not the lower 


bounds of the program, there are several ways of calculating © 


the beginning location. The easiest way is to use the 
address of the RB and add 20 hex to its value. This is 

. ' possible because the RB and its associated program are 
contiguous to one another. 
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a Analyze Current PSW_ 


What was the last instruction given in my program? . 
Normally the next step in debugging is to determine 
where, within the failing program, was the last 
instruction given. The assumption here is that your 
problem is most likely localized in the area that the 
ABEND was issued. The last instruction in our 
| example will be an SVC 13 which is ABEND. The 

* . answer to "where within the dump is this instruction 

located", can be found,in two places. Evaluation of — 
the 16 digit PSW UPON ENTRY TO ABEND printout 
is the first place. This is the current PSW as it 
existed upon entry to the ABEND SVC routine. It 
should be subdivided as shown in Figure 24. 


& 


SYSTEM MASK 


| PROTECTION KEY 
‘AMWP bits 
ms INTERRUPTION CODE 


 “FFO5000D ~~ .69.0046C2 


| L- — nerevorzox ADDRESS 


PROGRAM MASK 
INSTR. LENGTH ee & CONDITION CODE — 


bits 32 and 33 bits 34 and 35 _ 
OO - not available O60 2-0 
Ol - 2 bytes Ol -1 


10 ~ 4 bytes 10-2 
11 - 6 bytes 11-3 


Figure 24 


~37- 


= 


The two fields that are meaningful in our search for the 
last instruction executed is the Instruction Address and 
Instruction Length Code. The Instruction Address field 
contains the address of the next instruction that would be 
executed by the CPU. Make sure this address is within 
the program boundaries calculated earlier in Step 1. If it 
isn't, you're on the wrong track. Assuming the contents 
of the Instruction Address field points within the problem — 
program, the next step is to decrease this address by the 
Size of the last instruction executed. This value is kept in 


the Instruction Length Code and Condition Code field. 


The left two bits of this four bit field indicates the length 

of the last instruction performed.: In Figure 24, the last 
instruction length is 2 bytes, subtract this value hexadecimally 
from the Instruction Address field and the result (0046C0), 


points to the last instruction performed prior to ABEND. 


3. Additional PSW Information 


It is convenient at this time to talk about some of the 

other fields in this PSW. The AMWP bits are helpful 

in quickly distinguishing what mode the system was 

operating in when ABEND was issued. If the P bitis 

on, ABEND was issued as the result of something that 

occurred while the CPU was operating in the problem 

state. If the P bit is off, ABEND was issued as the 

result of a malfunction while the CPU was operating in 

the supervisor state. The Interruption Code field for 

an "old PSW" normally varies depending on the type 

of interrupt that occurs. [For instance, this field in the 

I/O old PSW, after an I/O interruption, contains the 

hexadecimal address of the device that caused the interrupt; 
this field in the PROGRAM old PSW, after a program 

interrupt, contains the program exception code of 1 to 15; 

this field in the SVC old PSW, after an SVC interruption, 

contains the hexadecimal equivalent to the SVC code. | 

This field in the "PSW upon entry to ABEND" will always 

contain QOQQD. ‘This fact could cause problems and will 

be expanded on in a later section. 


The RESUME PS8W field, in the RB associated with the 
program that issued the ABEND, will also contain the 
information as was indicated in the PSW printout at the top 
of the dump. 


-38- 


+4 


v 


_ User Debugging Steps 
What steps should one take in debugging a user 


created problem? This question can best be 
answered by stepping through a typical problem. 
Assume for this example that the completion code 


isa system code 06. The following steps should 
be taken. 


Qe 


b. 


Ce 


Determine, using the IBM Messages and 
Completions manual C28-6608 or the list 

in Appendix A, what type of error occurred. 
In this example, the error is a program 
specification. 


The next step is to evaluate the instruction 


address field of the "PSW UPON ENTRY TO 


ABEND", Using this address in conjunction 
with tne Active RB Queue, determiine if the 
program check was within the boundaries of 
the user program. 


Assuming the oroblem is within the user 

program, the next step is to pinpoint the instruction 
that failed. This is accomplished by evaluating the 
Instruction Length Code and Instruction Address 
fields in the "PSW UPON ENTRY TO ABEND", 

This procedure was explained earlier, 


Now, uSing the instruction address calculated in 


‘c, one should find in the hex dump the instruction 


that failed and determine its function. At this 


point the procedure will vary depending on what 


source language the program was written in. 


If the source program was written in Assembler 


Language, itis a simple matter to evaluate the 
instruction and determine, using the Principles 
of Operation Manual AZ2-6821, what could cause 
this type of programming error. 


If the source program was written in a higher 
level language one must evaluate the instructions 
prior to and after the failure to determine what 
function they are performing and tie this back to 


the source program. 
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system Problem 


As was indicated earlier, a system completion code does not 
mean that the user is free from fault. Careful evaluation , | 

of the completion code explanations and Active RB Queve is | OW 

necessary to pinpoint the problem area. It is difficult to | oe 

set up a precise sequence one should follow when debugging ce 

a System problem. The following are a few procedures : 

one might consider. 


1. Common Errors 


Some of the more common errors evolve out of 
improper use of the job control language. When 
this occurs the Active RB Queue will contain an RB © 

with a meaningful module name. This module name, 

- indicated in the NM field of the RB, allows the user 
to refer to the Job Management PLM, 228-6613, and 
determine what function this module performs. The 
primary step one must perform on system problems 
is to tie the problem back to a module and refer to the 
.PLM's to determine its function. 


‘Another factor to consider, when determining 

“whether the problem is in a user program, is that . | 
the access routines are branched to. They, therefore, . 
Operate under the users RB. [If one finds a high address a, 
in the instruction address field of the "PSW UPON . 

ENTRY TO ABEND", evaluate the Load List to determine 

' if the failure occurred within one of the loaded access 

routines. If the problem is within an access routine, 

refer to the proper PLM to determine the routine's 

function. 


25 System! Blocks 


How does one find the sy stem blocks not formatted by | 
the ABDUMP? Listed below are the meaningful system — 
blocks with an explanation of how to find and use them. 


as Communication Vector Table - (CVT) 


The Communication Vector Table provides the 

means for nonresident routines to refer to information 

in the nucleus. The address of the first location of 

the CVT is placed in main storage location 16 

(decimal) or 10 (hexadecimal). One should refer 

to the Introduction to Control Program Logic manual 

for the contents of this table. This table is useful - 
in finding the Unit Control Blocks (UCB) for system ~~ 
data sets. | | 
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Task I/O Table (TIOT) 


The Task I/O Table is constructed by job 
- management and resides in the higher portion 


of the dynamic area of main storage during 
step execution. It provides the I/O support 
routines (OPEN, CLOSE, EOV) with pointers 


- to the Job File Control Blocks (JFCB) and Unit. 


Control Blocks (UCB). The JFCB, which resides 


on disk, contains information specified in the 


DD card for a specific data set. The UCB's, one > 
of which is created for each device specified at 
system generation time, describes the device 

or devices allocated to a specific data set by 


the job scheduler. The TIOT would therefore | 


contain the following information about each 


= ‘data set described for a particular job step: 


a disposition and label status 

* . ddname of the data set 

** relative pointer to the JFCB ona 
DASD device 

* main storage pointer to the UCB's 


_ allocated to this data set. 


A pointer to the TIOT may be found in ao 
fourth word of the TCB. 


MSS.Boundary Box 


The Main Storage Supervisor's (MSS) Boundary 


Box is a table of three addresses. It is pointed 
to by the MSS field in the TCB. The first address 


in the boundary box points to the first Free Queue 
‘Element (FQE) of what could be a chain of FQE's 


which describe the free core within the system at 
any given time. Each FQE describes a block ‘of 
contiguous free core of which it is the first 8 bytes 


as shown in Figure 20. 


~-41. 


MSS Boundary Box 
1st FQE | 


* Last Addr. +1 


| 4 1st User Core 


! 
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Allocated Core 


ci 7:core 


_# Next FQE |# of bytes (X) 


8 bytes 
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The first 4 bytes of an FQE contains either; 

a pointer to the next FQE or contains zeros 

if it's the last FQE on the chain. FQE's are 

chained from the top of core (high addresses) © 

toward the nucleus. The Main Storage Supervisor 

allocates user ccre requests starting at the 

top of core and running the FQE's til the request 
can be satisfied. The second 4 bytes specifies 

the number of free bytes available in this contiguous 

block of core. This count is in hexadecimal and : 

includes the FQE size. | | | | | 


The second word in the boundary box points to | 
the first available address outside the nucleus. | 
The third word points to the last address in 

core plus one. All three of these pointers are | 
calculated and initialized by the Nucleus 
Initialization Program (NIP) at IPL time. 


It is important to note that ABDUMP does not 
dump free core. One can calculate the free core 
at the time of the dump by scanning the core 
addresses-at the left of the dump listing and 
noting the number of bytes skipped when non- 
contiguous addresses are listed. 


d. Data Extent Block (DEB) 
The DEB contains an extension of the information 
in the DCB. Each DEB is associated with a DCB, 
and is created at OPEN time. There is a pointer 
(word 3) in the TCB that points to the first DEB 
on the chain of DEB's associated with the current 
job step. If there is a DEB on this chain, then the 
data set associated with this DEB has been OPENed. 
The DEB is the key block with which the user can 
find all the control blocks associated with a 
particular data set. Figure 26 shows the control 
block structure and the pointers indicating their 
relationship used by data management. 


whe 


{ 


fo 


——o 


ae es eee ees 


Figure 26 


Input/Output Block (OB) 


The IOB is the communication between a routine 
that requests an I/O operation and the I/O 


Supervisor. All the information required by the © 


I/O supervisor to execute an I/O operation is 
contained in an IOB or is pointed to by the IOB. 
When an EXCP macro is issued by an access 
routine Register 1 contains a pointer to the IOB. 
This 1S an important fact to remember when 
evaluating the trace table. From the IOB, one 
cannot only find the other control blocks but also 
locate the list of channel commands (CCW's) 
performed or to be performed on a particular 
device. | | 
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Data Extent Control Blocks (DECB) 


The DECB is created by the expansionofa READ | 
or WRITE system macro. It is the communication 
link between the user and the access method. The 
access method in turn notifies the user of an 
completed I/O event by POSTing the Event Control 
Block contained in the DECB, This block provides 
synchronism between the user and the asynchronous 
I/O operation. 


Unit Control Block (UCB) : 


There is a UCB for each device attached to the 
system. It describes the characteristics of the 
device to the 1/O supervisor. The UCB is the only 
location where the user can obtain all the sense bytes 
passed back from the last Sense command to a 
particular device. 


Fach of these blocks are further defined in the Introduction 
to Control Program Logic Manual 228-6605. 
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ve Ve SAVE AREA 


To understand the save area trace and-its associated messages, 
one must understand what responsibilities the user has and what. 

functions the control program performs when different linkages 
take place within a program, 


A. 


ee 
( 
“/' : 
0000 || tare 
[TArea.2 Area. 


; Registers 


Word 2 
Word 3 


Words 
6 to 18 


save Area Chaining 


The following examples illustrate the chaining of save areas 
when different linkages are used, and relate the chaining 
sequence to the concept of control levels. Each example 
concentrates on (1) the use of words two and three of a save 


area, (2) the contents of Register 13 at the point of linkage, 


and (3) the responsibility of programs to provide save areas. 
Pointers to save areas in higner control level programs are 
shown as solid lines and called the back chain; pointers to 
save areas in lower control level programs are optional; 
are shown as dotted lines; and are called the forward chain. 


EXAMPLE:1: The job stream contains an EXEC statement 
for moduie ALPHA. ALPHA consists of Program A and 
Program B, which was included in the module as a result 
of a CALL macro-instruction. Program B contains a LINK 
macro-instruction to Program C. 


EXAMPLE 1 
| Program A’ | Program B 


| -CalltoB | Link toC 


: . 
_ | Registers i. Registers 


Save Area 1 


Area Pro- 


Area — 
Used by: 


saved:by <1 ‘saved by ¢ | saved by ie a : 
| AS | B yy Cc | ' [ 
sacsandl : ; se reed eco | 

l 


} 

vided by: Contr. Pgm. | Program A 
Program A ‘ 
\ 


Save Area 2 3 Save Area 3 Save Area 4 


| Program B Program C 


| | 

i oo 
Program B~ : Program C | Unused 
; 
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In this example, Program A is considered to be at the 
highest control level and Program C.at the lowest. When 
Program A receives control, word 2 of save area i, which 
is provided by the control program, contains zeros, and 


Register 13 points to this save area. 


It is Program A's responsibility to: 


* Save registers in save Area 1 
* place the current register 13 into its 
own save Area 2, Word 2 | 
OF place the address of Save Area 2 into 


register 13 and word 3 of save area l., 


This procedure insures that at the time of each linkage from 
Program A, register 13 points to the save area of the higher 
control level program. A similar procedure is necessary 
upon entry to Program B. Since Program C does not either 
contain a linkage to a lower control level or issue a system 
macro instruction, save area 4 is not required. (Program C 
need only save register 13 until the return linkage.) The save 
area is shown here for generality, since Program C might 
require the area during another execution. 


Example 2A and 2B: 


Program A receives control from a higher level program and 
issues a LINK macro-instruction to Program B, which in turn 
issues an XCTL macro-instruction to Program C. Finally, 
Program C calls Program D. The major consideration here 
is the use of save area 2 by both Program B (before the XCTL 
macro-instruction Example 2A) and Program C (after the _ 
XCTL macro -instruction, Example 2B). 
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EXAMPLE 2A 


‘ 
Word 2 
Word 3 


Words 6-18 


we 


Area 
provided 
by? 


Area used 
by: 


EXAMPLE 2B 


Word 2 
Word 3 


Words 6-18 


Area 
provided 
by: 


Area used 
by: 


£ 


* 
«. 
nf 
* 
- 
ware 


lal a eeeeeeeatae eeneen teria aannanencte tennemeaaiea ananed 


2 | 
| Program A Program B 
| | — | ies 
Link to B vas | 
SEE Pee ne attain ACTL to C 
2% ass, Shad, ( | y en ee 7 q 
tPri | [tArea 1 z | 
tAreaé =|" Area 3 
Registers Registers | 
saved by A | Saved by B 
| | . 
Save Area 1 | _ Save Area 2 Save Area 3 | 
Higher ff Program A a Program B | 
Level | | 
Prog. : 
Program A 
- 

! 
er = 
| Program A Program C ! 
| = = | 
| LINK to B CALL to D ! 

atonement : - | 
' ; LY 
te see es a 

Prior Area | *Areaa _ | 
‘Areag . ~ Unused } 
| : 
| Registers | fl Registers Registers | - | 
_— by A paved by C Saved by DS: 
eee eens a. 4 
Save Area 1 Save Area 2 save Area 3: 
Higher | ar | 
Level Program A Program CC, 
Prog. | 
: ; ! 
Program A Program C Program D { 

| - : | 

4 ae 

a 

I 
nag | | 


Save Area Trace 


This heading identifies the next lines as a trace of the save 


‘areas for the program being terminated. Each save area is 
presented in the dump in three or four lines as shown in 


Figure 27. The first line gives information about the linkage 
that last used the save area. 
the request block for the linkage cannot be found. The second 
line gives the contents of words 0 through 5 of the save area. 
The third and fourth lines give the contents of words 6 through 
18 of the save area; these words are the contents of Registers O 


through 1d. 


SAVE AREA TRACE 


PROGA WAS ENTERED 


SA 
RET 


02 


06 
10 


O0O3FFBS8 
00003180 
OQQO0006C 
00003130 
O0O38F FOC 


00033D04_ 
5003400F 
0003EDBA 


—Q008FCCO 


00033D90 


WD1 
BP 


00002449" 
400330D0 
00002449 
OOO00000 
OOO3 FP EF4C 


48D0A004 


OOO000000 


00033DCC 
00000008 
OOO00000 


INTERRUPT AT C34CAA 


PROCEEDING BACK VIA REG 13 


SA 
RET 
02 
06 
10 


00033D04 
0003400E; 


OO03EDBA — 


Q0038FCCO 


00033D90 


WD1 
EP 
03 
O7 
mt 


&8D0A004 | 


O0Q0Q000 
0003 3DCC 
00000008 


00000000 


Figure 27 


OOOQ0000 
QQ000030 
00005318 | 
Q0000038C 
00002448 


OOOSF FBS - 


19544078 

C807DAI6 
OOO3E DAS 
400338C D6 


O008FFB8 
19544078 

C807DASE 
O0O03E DAS 
40033CD6 


This line will not appear when 


00033D04 

0003 FF1C 
Q003 FE 4C 
4003A41A 


9A DOZ014 
O0033D90 


OQOO3EDAY — 


00034CA8 


DADOAOL4 


, Q00033D90 


OOO3E DAS 
000384CA8 


To provide a forward ieee: en Save area trace, the 
BAY LTEAS i presonted in the dump in the following order: 


a) 


f TON cnet a ad r 
ea oles ae ee eas. eae 


re ‘he save area pointed to in the TCBEFSA fteld ee? 
of the task control block, This save area is | 
the first one for the problem program; it was 
set up by the supervisor when the job step 
was initiated. 


” “ the third word of the first save area was 

| filled by the problem program, then the second 
save area in the dump is that of the next lower 
level program of the task. However, if the third.: 
word of the first area points to a location whose 
second word does not point back to the first area, 
the message INCORRECT BACK CHAIN appears 
inthe dump. This messade is followed by the 
contents of the possible second save area, 


ihe third, fourth, etc., save areas are then 
pre sented in. the | dump, if the third word was 
filled in each higher save area and the second 
word of each lower save area points to the next 
higher save area. This process is continued 
until the end of the chain is reached (the third | 
word in a save area contains zeros) or the message — 
INCORRECT BACK CHAIN BpPEeESs 


Following the forward trace, the line INTERRUPT A'T hhhhhh 
appears, followed by the line PROCEEDING BACK VIA REG 13. 
Next, the save area in the lowest level program is presented, 
followed by the save area in the next higher level. The lowest 
Save area is assumed to be the save area pointed to by the 
contents of Register 13. These two save areas appear in the 
dump only ft the contents of nnene 13 point te a full word 
boundary and are not zero, 


as MA Ae Seen A! 
cececcee WAS ENTERED 
The 8-character name of the program that stored 


register contents in the save area. This name is 
obtained from the request block, | 
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= 


VIA LINK (CALL) dddad 


ither the LINK or CALL appears, The word 
LINK or CALL indicates whether a LINK or 
CALL macro-instruction was used to give control 
to the next lower level program. The 5-digit | 
number is the ID operand, if it was specified, of 
the LINK or CALL macro-instruction, 


AT EP cecece.. . 


The string of up to 70 characters is the entry 
point of the identifier, This identifier appears in 
the dump only if it was specified’in the SAVE 
macroa-instruction that used the save area being 
presented, | 


SA Dhhhbhhh 

‘The $S-digit address of the save area being presented, 
WD 1 bhhhhhhoh 

‘The 8-~digit representation of the contents of the 

first word of the save area. (Use of this word 

is optional). 


HSA | hhhhbhhh 


The 8-digit representstion of the contents of the 
second word of the Save area; this word contains the 
address of the save area in the next higher level 
program, Jn the first save area, this word contains 
Zevces, Iinall other save areas, this word is required 


™ wy 
}: a a “eos 
aye 
OL ork a Or Ce oA he 


BoA hhbhhhhh 


The 5-digit representation of the contents of the 
third werd of the save area; this word optionally 
contains the address of the save area in the calied 
(lower level) program (register 13 contents), 


RET bhahhhhhh 


‘The 8-digit representation of the contents of tne 
fourth word of the save area; this word optionally 
contains tne return address (register 14 contents). 
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{ 2 | EP hhhhhhhh _ . ) | 


‘The 8-digit representation of the contents of 

the fifth word of the save area; this word 4 
optionally contains the address of the entry point 7 a. 
to the called program (register 15 contents). os 


00 hhhhhhhh 01 hhhhhhhh. . . 12 bhhhhhhh 
These 8-digit numbers are the contents of 
registers 0 through 12 for the program containing ! 
the save area immediately after the linkage. salt : 
2 SAVE AREA TRACE MESSAGES | 
INCORRECT BACK CHAIN 


This message indicates that the following three | ! 
lines in the dump may not be a Save area. 


co 


INTERRUPT AT hhhhhh 


The 6- digit address of the next instruction to 
be executed in the problem program. Itis 
obtained from the resume program status word | 
of the last program request block (PRB) or —_ . 4 
loaded program request block (LPRB) in the | i 4 
active request block queue. 


' EPROCERDING BACK VIA REG 13 


This heading indicates that the next two save areas | 
in the abnormal termination dump are (1) the save | i 
area in the lowest level program, followed by (2) { 
the save area in the next higher level. If register a i 
13 contains zeros, these two save areas do not | 
appear in the dump. 


TRACE 


The tracing routine is an Operating System/360 optional feature 
which you can use as a debugging and maintenance aid. The 
tracing routine stores, ina table, information per taining to the 
following conditions: 


*  _-“* SIO instruction execution. 
- SVC interruption. 
a T/O interruption, 


You can include the tracing routine and its table in the control 
program uuring the system generation process. This is done 


using the TRACE option in the SUPRVSOR macro-~instruction, 


The format of this option requires you to supply the number of 
entries in the table. Each table entry can contain information 
relating to one of the traced conditions. When the last entry in - 
the table is filled, the next ne will overlay the first. 


A. Table Entry Formats 


Table entry formats are in Figure 28. 


< 
Vv 


| t @ TO Instruction 
a. Ce a eo ae 31 15 
Device Channel | Channel Status Word - - 
Address | Address Word (Meaningful only when bits 
| i 2-3=01 
ir 7 3 
sto Condition Code 
I/O Interruption 
O 138 16 i9 310 31] 0 31{ 0 | 31 
| - a 0000 | ee Channel Status Word 
1/0 Old PSW 
SVC Interruption : . | | 
O13 _ 16 19 tO BOO | 
t 0001. | Contents of Contents of an . 
i | Register 0 Register 1 m 
Cs. SE ROE CRA -_ 
SVC Od pSw | 
i 
Figure 28 t 
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B. Location of the Table 


The addresses of the last entry made in the table, the 
_ beginning of the table, and the end of the table are contained 
ina lda-byte field. The address of this field is contained in 
the full word starting ai location decimal 20 (hex 14), The 
format of the field is as follows: | 


lo 31 


0 31 | 0 ool 
| | i 
: 
Address of the Address of the Address of the 


| Last Entry Table Beginning | ‘Table End . 
The tracing routine is bypassed during the abnormal 
erenanon procedures, 


- OF Trace Examples and Expl anton: 


1... SIO entry -~ A typical SIO entry is shown in Figure 29. 
This entry can be distinguished from an I/O interruption 
and SVC interruption entry by checking the fourth hex 
digit. If this digit is a zero then the trace entry is an © 

_  sfO. One would use the channel address word to locate 
_ the channel command words (CCW) which reflect the 
Operation initiated by the Start I/O instruction. The 
-, Channel Status word entry is meaningful only if the 
‘condition code, set by the SIO instruction, isl. This 
condition code is reflected in the first hex byte, bits 

2 and 3 of the first word printed. The unit address 

reflects the device which the I/O operation was initiated. 


90009190, Q0000FE8, 00000000 04000000 , 


\ianmstcntiae! asdll 


7 
UNIT ADDRESS : | | 7 


----- CONDITION CODE 
Figure 29 


265s 


[/O Interruption Entry - A typical I/O interrupt entry 
is shown in Figure 30. By checking of the fourth hex 
digit one may distinguish between an SIO and I/O 


Interrupt entry. However, to distinguish between an _ 


I/O Interrupt entry and SVC entry, a further check of 
the fifth hex digit is necessary. If the fifth hex digit 
is zero, then the trace entry is an I/O interrupt. If. 


_ the fifth hex digit is one, the entry is an SVC interrupt. 


By evaluating the I/O old PSW a number of facts can 

be determined. For example, the interrupt code field 
(hex digits 5 - 8) contains the address of the device 

that caused the interrupt, the AMWP bits (hex digit 4) 
indicates whether the interruption occurred in problem 
State or Supervisor state; and the instructions address 
indicates where the interruption occurred. The CSW 
provides the user with unit and channel status about the © 


device and channel that caused the interrupt. The first 


four hex digits of the second word indicates unit status 
and channel status respectively. 


FFOB0190 0000820A.. .001F708 


OC000000 _, 
re Nemes | 


1/O old PSW ; csw 


Figure 30 


In Figure 30 the unit status indicates a channel end and 
device end. No channel status bits were on. This 

Status denotes a successful I/O operation. The Principle 
or Operations manual should be referred to for further 
explanation of the channel and unit status fields. Upon 
determining that an entry is a successful I/O operation, 
the first'word of the CSW may be checked to determine 
what commands have just been completed. The address 
in this word reflects the last CCW address plus eight. 


In Figure 30 the last command to be performed is located | 


at 1F700, | 


J 
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3. SsVC Interruption Entry - A typical SVC interrupt entry 
is shownin Figure 31. The first two bytes contain the 
SVC old PSW. The last two bytes of the entry reflect 
the contents of Register 0 and Register 1 at the time the 
_. SVC interrupt occurred. These registers are parameter 
passing registers used by many system macros. Most 
system macros degenerate into unique SVC interrupts. 
Appendix A lists the system macros and their associated 
SVC numbers, The interrupt code field (hex digits 6 - 8 
of the first word) contains the hexadecimal value of this 
_ SVC number. 


In Figure 31 an SVC 0 or the EXCP macro was issued. 
Additional checking of the SVC old PSW will reflect what 
mode, problem or supervisor, and where the SVC 
instruction was issued, Also note that in the case of an 
EXCP macro, Register 1 reflects the address of the IOB 
for this 1/0 operation. By knowing the IOB location, one 
can find all the associated data management control blocks 
for this operation. 


/ | 
, FF041000 __ T0081E6 _, _000000F7 OOOLETTC , 
SVC old PSW - Register O Register i 


: 


Figure 31 


There is one case where the:SVC entry may be misleading. 
This occurs when a program interruption causes the | 
ABDUMP. Inthis case, an SVC 13 is placed in the trace 
table:that gives all indications that the users program 

issued the ABEND macro. Actually the system issued the 
ABEND using the PSW as it existed when the program 
ee occurred, 


4, What is the recommended method of using the trace table? 


The trace should be used to further pinpoint system and 
user problems. A Suggested procedure is to: 


a. find the last entry made in the trace table. 


b. ‘back up from that entry to the last SVC entry 
‘made indicating the problem state. 


57 ~ 


C. 


tle this entry back to some function pertormed 


| in the user's program. 


work forward in the trace table from this problem | 
state entry and try to determine what functions took 


place between this entry and the last entry prior to 
ABEND. 
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DASD DATA SETS 


‘This section will discuss the availability and location of information 


about DASD data sets that would be of interest to the installation 


programmers. 


The items to be covered are broken down into the following groups: 


The Volume Table of Contents -- VITOC 
Data Set Control Block -~ DSCB 


PartitionedData Set Directory Entry 


~The Volume Table of Contents (VTOC) Evaluation 


Prior to evaluating the contents of the VTOC one should under- | 
stand the furictions performed by the direct access device space 
management (DADSM) routines. 


ae 


DADSM 


Direct-access device space management (DADSM) 
consists of routines that allocate space to data sets on 
direct-access volumes. DADSM performs this function 
by maintaining the volume table of contents (VTOC), itself 
a data set that is included in every direct-access volume 
by the volume initialization utility program (DADSI). A 


VTOC contains a data set control block (DSCB) for each 


data set on the volume and for all unused space on the 
volume, | 


DADSM routines update VTOCs by creating DSCBs for 
new data sets and deleting the DSCBs of data sets purged 
from storage. When a data set is created or an existing 


data set is enlarged, DADSM finds unused space by 


searching the appropriate DSCB in the VTOC, allocating 

the space to the extent of the data set, and removing it from 
available space. When DADSM deletes a data set, it also 
removes the DSCB of the data set from the VTOC; and the 
extent of the data set identified in the DSCB is again 
available for future allocation. DADSM can also return 
unused space at the end of a data set extent to available 
Space by updating the DSCB of the data set. 


\ 


Additional information concerning DADSM can de found in 


IBM System 360 O/S Direct Access Device Space Manage- 
ment PLM - Form #Z28-6607. 


oe 


9 


Ge 


vire’.- Gisting ano Deseription 


The first step in checking the status of a DASD data 
set requires the execution of the IEHLIST program 
which will print the contents of the VTOC, 


_ The VTOC is a data set that contains a DSCB for every 


data set and for all available space on the Direct Access 
volume. The VTOC data set is always a single contiguous 


area. Its size and location are determined when the volume . 


is initialized by the VIOCD control card in the DASDI 


- dnput stream. Ona Primary Systems pack, the VTOC 


can be located anywhere following the IPL records and 


volume label. On other than Primary Systems packs, 


the VTOC can be anywhere following the volume label. 


The starting address of the VITOC is s recorded in the © 


prandard volume label. 


The iy eadionistics of the VTOC data set, following: 


volume initialization, are as follows: 


\ i. 7 | 
Qe The initial volume label contains the absolute 
track address of the VTOC data set. 


‘db. | The VTOC’ contains two DSCB's: 


1. The firstisa Ponmat 4 DSCB which describes’ 
the VTOC data set. This DSCB is always the 
first block of the VTOC. : 


Le The second DSCB,” a Format 5, describes 

ne the space on the volume not occupied by data 
sets. This is located immediately after the 
Format 4 DSCB of the VTOC, 

|| 

C; Every DSCB in the vToC is 140 bytes in length 
(44 byte key and 96 byte.data portion). Unoccupied 
space in the VTOC contains all zeros (Format 0 
DSCB's). 


0 aa A DSCB, Format 1, is created as a result of a DD 


card specifying a data set name and including a 
space parameter. The information from the DD 


card statement is included in the DSCB for investigation 


ane use by the oe routines. 
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8. Formated VTOC 


__ A sample formated VTOC of a volume with serial 
number 111111 is shown in Figure 32. For reference 
_ purposes, the information about the data set SYS1. LINKLIB 
- will be investigated, The following items are found: 


a. Created - This is the date that the data set was 
_ created. The date being picked up from the set date | 
command given by the operator during the IPL © 
operation. | 


fio? Purge - This is the date that the data set may be 
_ purged. This date is entered when the data set 
is created by a parameter of the DD card. 


c.: File Type - This item specify s the type of data 
. get organization. 


d.~ Extents - A data set may have up to 16 extents. 
: he extents containithe physical location of the data 
|  seton disk. Three extents can be contained in the 
Format 1 DSCB. If more are needed, a Format 3 
DSCB which can contain up to 13 extents, is chained 
to a Format 1 Pees to account for the 16 possible 
extents. , 


e. File Serial - This is the serial number of the data 
get contained in the DSCB, | 
I, 
f. | Volume Sequence Number - If the data set requires 
multiple volumes, this is the method of keeping © 
eee of the order of volumes. : 


ge: security ~ None at this time, 


Figure 32, is the formated IEHLIST of the VTOC. An example 
of a dumped VTOC will be covered later in this chapter. 
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SYS1l. COBLIB (cont; 


cence censenlaagee pes stmeain ene et cathe te tag Bie a ee wk ape meen 


4 ¥ 
CONTENTS GE VTOC CN VOL LiLLLL 
— DATA SET NAME 8 CREATED PURGE 
_ SYSCTLG meen sees veltne edhe ee ee eeu mentee be teste ee eevee ee, 01066. 35099 __ 
eee eee "97066. 35099. 
~ SYS1.SYSUCBCE 36917 26917 
SYSLeLINKLIE 07066 235099 
SYSLePROCLI28 07066 35099 
SYS1.NUCLEUS 08866 36598 
SYSLSSCRILIE | casas sem eet ones tand ae entne se eens etereesenelcnrmennee 01066 35099 | 
JSYSL.COBLIB | 0%066 _35099_ 
“''SYS1LeFORTLIG | 07066 35099. 
SYSL-OLCCKL IB - 36099 35099 
SYS1.08J 35599 | 35599 
Fe ASSEMULR. PASTER« TESTCASE O0L66 35099 
.weMACROGENsMASTERSPATCHES - 00166 35099 | 
SYSLeLCGREC hee ce tee ee ee BIG 35599. 
"EU MACROGENs MASTER«LIBRARY 00166 35099 
— FeASSENELReMASTER sPATCHES © : 00166 35099 
FsASSEMELR«o MASTER SLIBRARY 00166 °° 35099 


FILE TYPL 


NOT DEFINED 
“ "PARTIONED 


NOT DEFINEO 
PARTIONED 
PARTIONED 
PARTIONED 


, PARTIONED | 
_  PARTIONED. 


PAQTIOQNED 
PARTIONED 
PARTIONEO 
SEQUENTIAL 
_ SEQUENTIAL | 
SEQUENTIAL | 


~* “PARTIGNED 


SEQUENTIAL 
PARTIONED. 


THERE ARE CO67 EMPTY CYLINDERS PLUS 0012 EMPTY TRACKS ON THIS” VOLUME 


| THERE ARE ORAL BLANK DSCBS IN THE VTOC_ ON THIS VOLUME | 


SYSCTLG (cont. ) 


SYS1.SVCLIB (cont. ) 
SYS1. SYSJOBQE (cont. ).. 


SYS1. LINKLIB (cont, ) 


SYS1l. PROCLIB (cont, ) ' 
SYS1. NUCLEUS (cont, ) 


) 
SYSl.FORTLIB (con Ne -) 
SYSl. BLOCKLIB (Cont ) 
SYS,OBJ (cont. ) 


EXTENTS 


FILE SERIAL 


ae wsbioe fy “tae ae Adie se we’ ccm we 


SECURIT TY 


VOL. SEQ. 
O000L_. LLLII1,. .. 00000 stg 
wO000L TLL 000007 7 NO 
~OO00L LLL ~ “90009 NO 
00001 111111 on000 NO 
00001 Ll11i1 09009 NO 
00002 11111 00000 NO 


00001 - 
00001 
00001 
00001 
~0000i 
00001 
_OO00L | 
_ 00001 
00001 
00001 
00001 


LlLiL1 
L1ll111 
Lili. 
LiLiLL 
LLL 
Lilli 
111111 
111111 
LLibil 
Livi 
dQ 3431 


Figure 32 
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00000. 


09QG60 
00000' 
00000! 
990600 
00000 
9005990 
-90000 
“09000 
09000 
090009 


4, 


fp 


The Data Set Control Block (DSCB) 


For each data set on a direct-access volume, there © 

- must be a corresponding data set control block (DSCB). 

in the VTOC of that volume. A DSCB, which describes 
the attributes and extents of a data set, consists of up 

- to three physical blocks chained together to form one 

logical record (DSCB) ina VTOC, Each block is 140 
bytes long (a 44-byte key and‘a 96-byte data portion), 

and contains information used by data management to 

control access to a data set. If a data set resides on more 

than one volume, there must be a DSCB for the data set 

in each VTOC. 


DSCBs consist of blocks of which there are seven formats: 


fA format 1 block can identify any data set, except 
for the VTOC, on direct-access storage. Within 

‘its structure, it can identify up to three noncontiguous 
Nareas of a data set extent. Additional format 2 or 
format 3 blocks can be chained to a format 1 block 

‘to constitute one DSCB. 


| A format 2 block Aeeeetied an (vital sequential 
: data set. A format 2 block, if used, must be chained 

ito aformat 1 block. 1 : 
-A format 3 block describes multiple extents of a data 
“set if more than three noncontiguous areas are allocated 
A format 3 block, if used must be chained to a format 1 
or format 2 block. A:maximum of 13 non-contiguous 
areas may be described by a format 3 block 

i 

A format 4 block describes the extent of the VTOC 
It always appears first in any VTOC. One format 4 
‘block constitutes one DSCB and can not be chained 
_to other blocks. 


SA format 5 block describes up to 26 noncontiguous 
areas that are available for allocation on a volume 
Each area is indicated in a separate "extent entry" 

' in the block. Formatld blocks can be chained together 
if the volume contains more than 26 available areas 


t ' 
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A format 6 block describes up to 26 split-cylinder 
data set extents. This block has the same format 
as the format 5 block, but describes extents shared 
by more than one data set. Each area of an extent 
is identified in a separate "extent entry" in the 
block. 


A format 0 block is sveivenis Space in the VTOC, 
‘The block contains all zeros, and can be imagined . 
asa "hole", When a data set is deleted from a 
volume, a format 0 block is written over the DSCB 
of the data set. 


Except on basic operating system volumes and on volumes 
' containing split cylinder data’sets, the total number of 
tracks accounted for in all DSCBs of a VTOC, at any time, 
is the total number of tracks on the volume, The unused - 
tracks are identified in the format 5 DSCB, and used 
tracks:are identified in pies of format 1, 8, and 4 of 
data sat DSCBs, — 

ie 
When é data set is created, the ALLOCATE routine finds 
Space on the volume by searching the format 6 DSCB. A 
new DSCB is created for the new data set and is placed in 
the VTOC in the first available hole (format Q block). 
When @ data set is deleted, its format 1, format 2, and 
format 3 blocks are replaced ‘by format 0 blocks (holes), 
and the extent used by the data set is returned to available 
space a e., added back into the format 5 DSCB). 


The DSCB of one data set consists of one, two, or three 


‘blocks, depending on the access :method used to process 
the data set, and onthe number of noncontiguous areas. 
in the data set's extent. The blocks aré chained together 
in the VTOC in the following sequences:: 
I | | 
a. A format 1 block alone for a data’set with an 
extent of not more than three noncontiguous areas. 
b. A format 3 block chained to a format 1 block for a 
data set with more thanithree noncontiguous areas. 
= . ce | : 


Ce A format 2 block chained to a format 1 block for 
an indexed sequential data set with an extent of 
no more than three nencontiguons: areas, 
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d. A format 3 block chained to a format 2 block, 
_ which is chained to a format 1 block, for an 
indexed sequential data set with an extent of more 
than three noncontiguous areas. 


The blocks of one DSCB do not necessarily appear in the VTOC . 
as contiguous blocks or in a defined sequence. Except for the 
first and second DSCB blocks in a VTOC, new blocks are 
placed in the hole nearest the beginning of the VTOC when 


-- . they are. created. The relationship of two blocks is shown 


by chain addresses. . 
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Dumped VTOC 

From the previous section it is seen that the DSCB 
contains all the information about data sets. When the 
IEHLIST program is run requesting a Dumped VTOC, 

the result is the DSCB listed as shown in Figure 33. 
We will again look at tne data set named SYS1. LINKLIB. | 
There are a number of items that did not appear in the 
formated VTOC. In order to easily decipher the Format 1 
DSCB bytes, two templates will be used. These templates 
are shown in figures 35 Eouga 38, 


Assume that the Sharecterities of the SYS1. LINKLIB 


; data set listed below § are needed. 


a type of eanbneten 


a 


b. number of extents 


¢c.! location of the first extent 


d. record format : 
e. : block length 
fi. secondary allocation | 
By. placing the template, aie 35 and 36, over lines one 


and two of the DSCB, the items above can be answered as 
follows: 


a Item K--2 bytes--0200--Bits 0000 00 10 0--0 
| pit 6 is on--Partitioned Organization. 
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b. Item F--1 byte--O01 extent 

C. --not found on line 1 or 2 

d. Item L--1 byte--CO Bits ‘1100 0000 11 - undefined 
e, Item N--2 bytes~-0400~-1024 bytes 


te Item S--last 3 bytes of a 4 byte field--000000-- 
no secondary allocation. 


Item C does not appear on lines one or two so template, 
Figures 37 and 38, will be used to look at line 3 of the 
DSCB. The first extent location description is Item C -- 
10 — -~ 


First byte 81 -- The extent begins and ends ¢ on 
cylinder boundaries. 


uw 


mecona byte 00 ~« Extent sequence number. 


i 


Third - Sixth bytes -- 00 14 00 00 lower limit 
4 Cc C H H of‘extent 


Seventh - Tenth akcie -~ 00 3B 00 09 upper limit 
CCHH of extent 
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a ge pe ee a -set ane a ae et ae tee cethat eee cS aeen ene 


fi 4 | | ) SY aTAMS SUPPUR, = 


| 

Ra Aeae Les Aacetes HS eg Sie ae ae So hee Eee ate: Gey Side tes - pla aad, Ge Rae Bi Re cera aie Ska) aera etal anaes Bh alias eB me ee Bes eee oan eas 

wotee ee we eee ee oe GUNTENT SO UF VIUC UN Vou LALLA 0 acre ccs oe ee cece ee. | 

> LINE 1 = USNAME | Soh OS ee ce HO ws US ce et ae 

a IVs 3 A: ee ve ce SO! wm ee ee ee Beh 2. o> Ge -d ws. & el te +6 205: 

a LING 2) S100 we veo TOU ww. & TAY ce wie Bie ow Oe owe OS: oe 2 TBO 

ae FURMAT 4&4 LSues VU Oe 04 O44 04540404 04060690404640464 

efi reer e FAGOUIUGE2U L0UL2OUL GOUT GUL LE UUUL LULU VOC D VOVAUE 2 9523,7140 1021910 

4B ena wee» UCOVVQDOQVVOCCTI GU0LY UICUIEUIUYUUTFO0UCUUVGTUOUOOND0V0NDN000OCONCOS 

4 a | FURMAT 5 Doeo GVoIVsoOvUSOGOLOOUCIUUYSC3ECQOULUCOL2Z200Z2A09NUC 

7 FSUGUUGUUOVUGUVUGUU UU UU UO UO UU DOU UULUUUUUUUUUOUGOGONONUGOOUUUN | 

pe OUYEOVUGUUOUGYLUUGU GE Guu Us LOGULIUGI0U0VOU0I0UGLOGOOO00000000 
a SYSi. LOURKEL 


Data e ee OMT eRe eT nT rT 

a ye OSL4SO4ALUGUUSLOLGUG AUUGU UU UU a 
2 SYS. SYSJCBKE- 

a aa ao ate ee Soe earn C eee CT CVUGUGUVVQIUVVVOVUUUGO000U00 paeece 


ad SLOFrFELOU0C LUUGUU SCUUGU Ue BUD OY GUUUUO0U5UG0090600000000000006 
: | ee. kei 


' 


vialetta wie ae wie FLELPAFLF IP LE Luv00GCUU0Ue 201 6VULOUUDUO0V0000GU0000060060C06000 
A sakes dase » 400209 LUQUUCULOOGGCALCUUGEUU 39V0IVO0U0I000000000090U000G000C000. 

_ SYSLeLINKLIE. 
_ FLFLFLELELELE LUUGOLOUU i0oru 1606106000000000900G0060000000000000 
ae FSU S09YCSZOUU CHU LOGOULS OSC UU ou ULOGUUC O00 GU GUUUUUN000 000006000000. 
. SYSCTLG : | 
a She aE. ses PIF EFLEAS LF LE LGUGGUCGCO0E ZU! OVELLLEYULGUOQVIGOGUODVLVDVCOOD0UCOGGO0U 
at ae .  mOUFFORLITGGUIY LUGOOSLUGU0LU 3c Ud090G0U0UU0G0G9090000000000600600 


ee & ee S ee we or ee a ee ee Oe, 
a o © ° G Q) ro a ‘ o rh 5 Od = a e Di) e e & 9 5 . @ e e 
ae > 2: ee A we AD OSCB ACDR (CCHHR) 


O46 040404 04040) 864 404040404040 4040404904940404 
JAUQVOUDCOGGGSCE SUE tOuSOOGVNOHOUOCOOD0NNNNNGNCVONCOCN | 
OOOO ODNDGNICAGOGUGQNG | Ss 9O0E000001_ . 
Format 5 (cont...) O0DD0G0NCOUVE GU »GodUe0000000RCD 9009000000000C9U00 © 

_ 0000 060C05UH050LN000000090060000000090CGAL000GC0 * 

‘QOOQVIGOCUUUEUGE GON ~—6O0090NNO2 


_Format 4 (cont. ) 


- «© 


ont. ! 
SYS). LOGREC (c - eI "90000 QUDD vO Cee ESR UCO02460G0002 090CNC00000C09090 


es 0000 OVGULO4 UeGGu8guO oo uw 00090090003 | 
~SYS1,SYSJOBQE (cont. )__ 


OUGOOGGE PE ODOROOGOGOCVIINNCD NOON QNGOHCH 
0060 DOO eee ee OO09000004 
cont, 
~S¥S1,SVCLIB \. a ‘DO0NGONOOULG Ln ON AG CO400000CCO000UNV0GNN0G QC0009 . 
DOVDGEOOGOUGHEGEERGS — ~ 0009000005. se 


_LINKLIB (cont.) | 
SYS), LINDE (ont G04000C0000000000800N00080G0 


CODOOCGUDULE We 0 0009000006 
SYSCTLG (cont. ) | 
ee 1 CORES OONOOUGEUoL ur He aNDgoDOVaGOaCOOLOOLOOOONNDA 
QOMDOIOGQUUCR SE | QO cud... «=OG9Q0U000T Ld. 


. rr ee od Cte dal ne de eae tn a in eect tr ant hd Latte chia tsa th niet he ken din cin eiehthahaah tie neil beatecih nee emiiianaliiataiedaeia ihe etal icine dtinins Minentins Meee AO REE PRIOR TIO YY 
Tx aie eilaetenins Deiien dae cates ieee a GR an 


an Tah, DATASETCONTROLBLOCK is th 
ee FORMAT 1 LINE 1 and 2 L. 


@) 1 Format identifier - Hex F1 

(B’ 6 Data set serial number | 

Cc 2 Volume sequence number | | | | 
D: 38 Creation date - ydd- . | 


where. y = year (0-99) 
oe : dd = day (1 - 366) 
(ey 8 Expiration date. _ 
of 1 Number of separate extents | 
- . G)_-1 © Number of bytes used in the last PDS directory block 
_ (1-7 Reserved for future use | 
_@ 13 System code to édentify the programming system 
| ; 2 Data set organization 


Specified Bits _ Settings Meaning 
| 0 


Reserved for future use 


BS 1 1 Physical sequential organization | 
DA ao = Jd. Direct organization 
Be5 F Reserved for future use 
PO , §@ oH SL Partitioned organization 
Ww ny re * ° Unmovable - the data contains 
; P location dependent ir infoymation 
2nd Byte - Reserved for future use | . 


®:. 1 Record Format : 1 


- Specified Bits: Beings Meaning 


EF © 0-12. °10 Fixed 
V © Quel ® OL .Variable 
U Onl | 11 ‘Undefined 
T © 2 . 4 Track overflow 
.B 3 1 ‘Blocked::may not occur with V 
S 4 1 Standard: no truncated blocks or © 
unfilled tracks are embedded in 
: a the dataset 
A 5-6 ' (10 ASA control character 
M 5-6 . Ol Machine!control character 
| : BeB ! O00 _ No control character 
cd rs Always zero. 
Data Set Name 
i 
Figure 35 a | ar 
oe 
-68- : : 


bol 


MPR DD Wr 


TY YR ORAS 
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DATA SET CONTROL BLOCK c* 


FORMAT 1 LINE land2R. 


1] 


Option code - same as DCBOPTCD field in DCB | 
Block length for fixed length records or maximum block for , 


variable or undefined length records 
Logical record length _ | 


Key length 


Relative key position in itis data block. © 


Data. set indicators 


Bits Settings Meaning 7 
0 = 1 : This is the last volume on which 
| | this data set normally resides 
1 te | Reserved for future use 
vy iL. | ~ Block length must always be a 
| | . multiple of 8 bytes 
3-7 | Reserved for future use — 


Seeondaes Allocation 
First. pte - Allocation parameters : 
as [ 
This field indicates the type of request that was issued for 
initial allocation and is to be used for subsequent extensions. 


Bits Settings | Meaning 
O-1 00 | Original request was in tracks relative 


i _ toa specific location.: No secondary 
allocation will be allowed 


O-1 QL. Original request was in blocks (physical 
- | records) 
Q-1 ‘10 | Original request was in tracks © 
O=1 alt | Original request was in cylinders © 
a=3 | | Reserved for future use 
4 be _ Original request was for a contiguous 
: a ) - extent 
O 7 7 Original request was for the maximum . 


contiguous extent on the volume 


6 : ee | _ Original request was for the five (or - 


less) largest extents that are greater . 
than or equal to a specified minimum - 


| : 1 Original request in records was to be 


rounded up to a'cylinder boundary 


Last Three Bytes ~ Secondary allocation anny 


The contents of this binary field indicate the niimber of blocks, 
tracks, or cylinders to be requested’ at end of data set ween 
processing a sequential data set. : | 
Figure 36 | au 
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DATA SET CONTROL BLOCK 
FORMAT 1 LINE 3 L. 


~ Last block pointer: The contents of this field identifies the 


last block written in a Sequential or partitioned organization | 


data set. It is in the format mace 


TT is the rélative address of ihe track containing the last block. 
R is the block number on that track 


| _ is the number of bytes remaining on that track following tha plock 


If the entire field contains binary zeros, the last block pointer does 
notapply, > 7 _ 


Reserved for future use. 


First extent description 


Cl First Byte ~ Data Set extent type indicator 
Hex } 
Code Meaning | 
OO Following 9 bytes do not indicate any extent. 
O1 The extent contains the data blocks (user's 
blocks) 
80 The extent described is sharing one or more 
: cylinders with one or more data sets 
81 The extent described begins and ends on 
; cylinder boundaries, i.e., the extent is 
composed of one or more cylinders 
C2 Second Byte - Extent sequence number 
C3 ‘Third ~ Sixth Bytes - lower limit of this extent (CCHH) 
C4 Seventh - Tenth Bytes - upper limit of the extent (CCHH) 


second extent description - same format as SDIEXT1 


Figure 37 _ 
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_ DATA SET CONTROL BLOCK 


FORMAT 1 LINE 3R. 


Third extent description - same format as DSLEXT1 


Pointer to Format 3 DSCB if a continuation is needed to 


describe this data set. ‘This pointer has the format CCHHR. 


DSCB ADD (CCHHR) 


Figure 38 
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Extents| | 


There is a possibility of having a data set composed 
of up to 16 Separate extents. The Format 1 DSCB 
can contain 3 extents. Further expansion of the data 


set requires a Format 3 DSCB to contain the extent 


information. The following discussion describes the 
Format 8 DSCB and also shows how it is located. 
Refer to|Figure 39 and the description of the Format 3 
DSCB in|the Introduction to Control Program Logic 
Manual 428-6605 to follow the example given. 


The data|)set, SYS1.UT3, will be looked at by using 

the templates of Figures 37 and 38. Itis seen that 3 
extents aire used in the Format 1 DSCB, There isa 
pointer om line 3 of the.Format 1 DSCB to 00 05 00 00 OF 


(CCH HR). At this location in the VTOC there is a Format 


3 DSCB. | This DSCB contains extents that are part of the 
data set, |SYS1.UT3. From the introduction to Control 
Program|Logic Manual, it is seen that there are 13 - 10 
byte fields that are similar to the extent fields of the 


Format 1) DSCB. 
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SYS{.UT3 | 7 _  . @ 
eee 28 F1C4 0B8C9C2F 0F 200004 200654200651 00U00000000000000UGUH 
00000 29000C01G000000007 000603070101 00G0000800000008 
SY bbe SLATE LE | 

Pigs BUG CSP CP LUC CLCLULULORC Lot CLOCIG SECO CU UOUGIUCUL 


. LENO TEE 106 COLUEUL 94 UIUC UCU bey Ca CU COUN Ju000D 00000C 


_ 


on SS smb © Meme se + ft eo -"s m 4 


20} tilele Pcie esetu ous cH2CCvEuluvugeGucllJVUUUsUUCUE 
" 4 U2iUL 6 SUUECEL COC WU sdu GUSUE EES LYE IHITIOVUDI VOUT 
4B SYSL.ALCLELS 
re | FLS iF PLE Le Le DUS CONC 142 CC Ta CIC URC COCs CouGde! ICOGGE 
we UBU SESE LULL CULGEEE Se COC SSE UUE4 OUI OU IVOIUI I IGUI GE 
= FURMAT 2 USus us wVSU3 SULGSUL SUCCUUUCHUUG jU0N] 
¥ aa £50 UT PESUCSSawen NOUS ucubu sce sens 100050 10 yuenucO 
ar | CULGLEBOCOCUSCLUILE DL UG CUCUSTUCUGULUE CES LONG 1005 LUO) 
a #8SYSUTL 7 
_/ 


VUYUCGUGTUUVUOUCUEC USC UCO0OCUUGUGCC COCOOCOCQ000 vGovoo0sauccdo loo 
VlYUZ2IC VVVUSTGUIUIOCS IU US IUUUGE ) OVND5000900A 


ssi VOls WU Vox sae 


VUYCVIDUIUGIIVAGO IC 2OCLICV200C 00004 660000000000068090000A00 © 
OUDVIDUOCOGdGVG0NGUOSUNINNGIOO | ~~ 9005000008 | 


soduoshocodLCoIVELEOLVI40ECHHIOCO2EC02602 COD0CCBE00G000NO 
NOOQVGOIVYOUCGOCDVGIUGCVOVN DODJOGC O0G0SO009OVIC 

QOIVGIVIO GUCIITGOIGICIIIID 200 GGCC4C00600000C000008000000400 
VOUVGIGCNVUNC OVI GUE OSOUGIUOOUUTO = 90050009000 | 
Val CCGG LUV SCOVILGLUSCUSOCUG2Z605000020106C0656006300500003 


VODUSIOU VOULUACESUTIVU TOUS OOIOTOLOBOVSINIVOIECUSO9NNO08NLOCCOS5Y 
VIDFECSLOUG2IVs LUCU2!ccaceeCCCU OCOSQVOO00E 


com _ cs @ 2 @& 2 @ @ HH 2 S@' eB A 


Figure 39. 
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2. Dire 


Paftitioned Data Set (PDS) Director Information 


The output load module produced by the linkage editor 
contains all the information necessary to load and relocate 


the module 


control j 


in main storage. When the load module is placed 


in the io odule library, the name of the module and 


in the lib 


ormation describing its characteristics are placed 


ry partitioned data set directory. Pertinent 


information abput the load module, such as the module 


attrioutes are tsed by the Control program fetch routine 


‘when the program is loaded for execution. They are also 
’ placed in the status field of the RB associated with the load 


module. It's important, therefore, to be able to locate this 
type of informs tion in the PDS directory. 


1. Directo y Organizations 


The PDS |directory occupies the beginning of the extent 
allocated|to the data set on a direct-access device. 

The dire¢tory consists of variable-length logical records 
arranged|in ascending order according to the binary 
value of the member name or alias, 


The directory récords are blocked into 256 ~ byte blocks,. 


each 


containing as many complete entries as will fit in 


a maximum of 254 bytes. 


. Bach 
TTR, 
field. 


logical record in a directory block contains a name, 
and count field.. It may also contain a user data 
The last logical record in the last active directory 


block has|/a name field of maximum binary value. 


The 
with 


tory, Contents 


ethod of investigating a member of a PDS starts 
he execution of the IEHLIST program with a LISTPDS 


control card included for the particular data set that 
contains the member in question. 


The information listed as a result is shown in figure 40, 
The contents of the PDS directory entry, Format 1, 
can be us¢d to answer the following questions: 


a. 


What is the relative location of the member in the 
data set? 


How much core storage is required? » 


Is the member name an alias? 
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d. 


e. 


Is the module in overlay structure? 


What are the System Status Indicator Values? _ 


Using the template, Figure 41, and the member IEFABDLOO 


shown on Figure 40, the following values are found for the 
above questions: 


The relative TTR is 001907 ~ Item B 
00 00 AOvss Contiguous Core required - Item F 


Bit 0 of the indicator byte is zero,. therefore, name 
is not alias - Item B 


Bit 2 of attribute byte one is zero, therefore, 


not overlay structure .- Item E. 


00 05 31 36 ~~ SSI bytes -- Item J 


Directory Size and Number of Entries 


he PDS Directory entry provides ready reference 
o information about a member of PDS. 


It may be necessary to expand or contract the size of 

a PDS. ‘In order to do this you need to know how many 
directory blocks are needed and how many entries can 
be contained in one block. © 


Ihe following method can be used to look at a PDS 
as it appears on the DISK. 


A 


Using the IERPTPCH program, define the PDS 

as a sequential data set. This will cause the 
directory to be printed. Each directory block is 
206 bytes long so it is possible by inspection to 
check the number of directory blocks that were | 
specified. The number of entries per block can 
also be determined by inspection. 

Using the IEBPTPCH program, define the PDS as 


a PDS and select any or all members of the data set 
for listing. 


Refer to SRL C28-6586-1 page 38, for further 
information. 
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PARTITIONED aie SET (PDS), DIRECTORY-ENTRY - FORMAT 1 1 


ee ee EE 8 OD © ane Abe Ae seem an oem 2 on. memes Tees am 


. 


® ‘MEMBERNAME | ae . @® Second Byte ug 
@®) 3 TTRof the first block of the named member | Bit 
1 Indicators ° Bits: Settings Meaning | 
Bit: . 0 1 Module can be processed on! 
Bits Settings Meaning | | by F level of linkage edit 
0 1 Name is an alias S 0 0 Module can be processed ty 
1-2 (variable) erga of TTR's in the user data " levels of linkage editor 
| ; fielc. A maximum of three is allow 1 | Linkege editor assigned cric 
38-7 (variabie) I Length n of the user data field in helt | of first block of text is zero 
words, ; 1 0 Linkage editor assigned oric 
€) 3-TTRof the first t bloc ck of text : _ of first block of text is noi z 
YT Zeros | | © 2 1 Entry point assigned by iink: 
© 3 TTRof the Note List’or Scatter/Translation Table. editor is zere 
Used for modules in scatter load format or overlay 3 L- Module contains no RLD iter 
Structure only. 4& 1 Module cannot oe recrocess: 
1 The number of entries in the note list for modules | by linkace editro | 
in overlay.  Stru — otherwise zero. ° 9) 1 Module contains THSTRAN . 
3 Total Koes tiguous main storage recuirement of module | oe _symbo! cards | 
GQ 2 Length of the first block of text > 6-7 Reserved for future use» 
HH 3. a pate aceress associated with member name or a 
with alias name if the alias indicator is on 1 byte — 1 byte 2 bytes 
CG) 3 Linkage editor assigned origin of the first block of text oe foe ge en ee 
© 2 Attribuies -. a. @: Change {| Flag Byte 1 Serial Number {| 
3 Rit First Byte i Seca: 3 | 
| | Ma eee ea eee oe ae 
Bits Settin Meanin | 
od Reenterable | M Flag 
a 1 eae ritical Flag - 
2 1 In overlay structure —Dependency Flag 
3 1 Module to be tested - TESTRAN L______-Product-Tempora: 
4 i. Only loadable Fix Flag 
4) 1 Scatter format ; |______Tocal- Pix Flag 
6 i Executabie | Force flag 
T 1 Module contains no RLD items and only enrol erved) 
_ | one block of text an | 
7 0 Module contzins multiple records with : | Format of SSI By tes 


at least one ciock of text 
| Figure 41. 
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- APPENDIX A 


ie This appendix contains two lists: the first is a list of those macro-instructions 
whose expansion includes an SVC instruction and the SVC number (decimal) associated 
_ with that instruction; the second is a list of the routines thatperform the services 


— yequested via the SVCs and ae program oS manuals (PLMs) in which these pee 
. are described: | | 


| | VC Hexa- | SVC Hexa- 

' Macro-Instruction _ No. decimal Macro-Instruction 7 No. decimal - 
ABEND = ~——«iA3.—s«OD—s—SsS CO; 31 IF 
“ATTACH | | Ae 2A FIND ¢° 18 12 

- BLDL ~~ ‘18° 12~———~*«&RRREEEBUIF 57 «39 
‘BSP : Bo 45 FREEMAIN 0508 

- CATALOG e6o1A GETMAIN Of oO 

- CHAP an) rye IDENTIFY ar arr 
CHKPT B00 822i INDEX 2600 1A 
GIRB 4300 OB LINK 06 06 
CLOSE - _ 20 14 IOHALT 33 21 
CLOSE (TYPE=T) ° ~3 17 LOAD 08 08 
DELETE en: 09 / LOCATE | 26 1A 
DEQ 48 = -30 OBTAIN a 27 1B 
DEVTYPE a 18 OPEN 19 «18 
DETACH «62 OPEN (TYPE=J) 22 16 
ENQ 06 = t(ité'B’ POST 02 02 
EOV a: 37 PURGE 16 10 
EXCP 00 00 RELEX 53 35 
EXTRACT | — 40 = 28 RENAME 30 1B 

syC Routines 


~-18~ 


a 4. 


| Appendix A, Page 2 
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1 
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- | SVC Hexe- a SVC Hexa- 
. Macro-Instruction No. decimal § Macro-Instruction No, decima 
- RESTART 528 - SYNCH 7 12 OC 
| RESTORE | 17 ig! TIME : il OB 
SCRATCH —«4.—o-99'”—s TTIMER 46 sok 
SEGLD 37 25 WA ok 
“SEGWT 37-25 WAITR Ol Ok 
SPIE 14. OF | WTO 35 23 
STAE | 60. 3c wroR 35. 33 
STIMER ese WTL 3624 


STOW 21 «15 XCTL | 072» «O7 


SVC Routines 


Ey (ops 


; ere Phe s Seas, US 
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In the following list, 


referred to in the associated 
System 
numper indicated is the domi: ant one and is tne type assigned unless the second number is 
explicitly specified. 


Use of an SVC numper that has 
nonsupported SVCs fall into this category. 


se of the: faneenina nonsupported SVC numbers is effectively a 
interruption will 


tion. 


ROUTINE 


NAME 


_EXCP 


Wait 
Post 
Exit 
Getmain 
Freemain 


Link 


_ &XCTL 


Load 
Delete 


| Getmain/Freemai) 


Time 

SYNCH 

ABEND 

SPIE 
ERREXCP 


Parge 


Recs tore. 
BLDOL 
Open 
Close 


Stow 


OpenJ 

Tclose 
DEVTYPE 
Track Balance 


Catalog 
Obtain 


CVOL 


Scratch 
Renane 


EOV 

Allocate 
IOHALT : 
Master Command 
EXC? 

Write to 
Operator 


Overlay 
Supervisor 
Resident SVC 


3 


WWe EW 


in the. 
interruption handler to abnormally terminate 


TYPE 


FENUWY PNENP FPRNNN BPPRPEE 


f&eewet 


Were 


= 


the 


*ROUTINE NAME‘ 
job step. — 


exit 


"TYPE" 


field. 


field 


routine. 


PLM 


indicate 


no-operation 
occur, but after the SVC interruption handler analyzes the: 
gvc, it immediately passes CPU control to the SVC 
. unassigned SVC numbers cannot| be assigned to user-written SVC routines. 


‘ROUTINE NAME‘ indicates the name by which each SVC routine is 
Two entries in the 
generation time, the |user can choose either type for this SVC routine. 


causes the Svc 


All unassigned and sore 


instruc- 


Nonsupported or 


Input/Output Supervisor 


Fixed-Task 
Fixed-Task 
Fixed-Task 
Fixed-Task 
Fixed-Task 


 Fixed-Task 


Fixed-Task 


' F3xed-Task 


Fixed-Task 
Fixed-Task 


Fixed-Task 
Fixed-Task 
Fixed~Task 
Fixed-Task 


Supervisor 
Supervisor 
Supervisor 
Supervisoge 
Supervisor 


Supervisor 
Supervisor 
Supervisor 
Supervisor 
Supervisor 


Supervisor 
Supervisor 
Supervisor 
Supervisor 


Input/Output Supervisor 


Input/Output 
Input/Output ¢ 


Su) Oey A Son 
Supervisor 


Sequential Access Methods 
Input/Output Support (CPEN/CLOSE/EOV) 


Input/Output Support (OPEN/CLOSE/EOV) 


Sequential Access Methods 
Input/Output Support (OPEN/CLOSE/EOV) 
Input/Output Support 
Input/Output Supervisor 
Sequential Access Methods 


Catalog Management 


Direct Access Device 
Catalog Management 

Direct Access Bevice 
Direct Access Device 


Input/Output Supvort 


Direct Access Device 


(OPEN/CLOSE/EOV) 


Space Management 


Space Management 
space Management 


(OPEN/CLOSE/EOV) 


Space a ec 


Input/Output Supervisor 


. Job Management 


Job Management 


-..Fixed~Task euperveecr 


RO - 


‘TESTRAN 


Not Sunnoreed in this configuration 


SVC Routines 


that at 
The first 


‘a 


sve ROUTINE 


* NUMBER NAME TYPE PLM 
J 39 ++ : Unassigned 
GO Extract 3,2 Fixed-Task Supervisor 
41, Identify es 3,2 | _ Fixed-Task Supervisor 
U2 Attach 3,2 Fixed-Task Supervisor 
43 CIRB 3 Fixed-Task Supervisor 
44 | Not supported in this configuration 
“GS Overlay | | | . 
Superviso 20 Fixed-Task Supervisor 
46 : Ttimer , 1 Fixed-Task Supervisor 
47 Stimer 2 ' Fixed-Task Supervisor 
48° | . : Not supported in this configuration 
49 Ttopenl | 3 TESTRAN . . 
50 | . Not supported in this configuration 
51 ABDUMP y Fixed-Task Supervisor 
$2 Not suoported in this configuré tion 
53 | dias | ms | Not supported in this configuration 
«54 . ** St Not supported in this configuration 
55 EOV | 4 Input/Output Support (OPEN/CLOSE/EOV) 
| Sequential Access Methods 
56 | Not supported in this configuration 
57 alg Not supported in this configuration | 
58 *% Unassigned * . 
59 we | 7 Not supported in this configuration 
60 : . Not supported in this configuration 
6. Save 3 TESTRAN . 
o2 Not supported in this configuration 
63 aid ; | Unassigned 
_ 64 RDJFCB 3 Input/Output Support (OPEN/CLOSE/EOV) 
6.) ve Not supported in this configuration 
66 is Not supported in this configuration 
67 as | ° Not supported in this configuration 
68 ye | Not supported in this configuration 
69 Backspace 3 Sequential Access Methods 
70 GSERV 2 Graphics Access Method 
71 my Not supported in this configuration 
72-199 “ Unassigned 
200-255 Availaole for assignment 


to user-written SVC rou- 
tines. Until a numper is 
assigned, |its use ina 
processing | program 
. causes termination. 
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Request Block Queues 
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TCB 


gure i. 


“a2 
oa a 


eae This is a breakdown of the status bytes (STAB) in the Request Blocks | 
D | _ (RB) for the sequential system. 


ee, 


bits C123 4967 891011 12131415 
: staH0000]0000. 0.0 0,0 0 0 0 


0 | Used to distinguish between PRB, IRB, SIRB, and SVRB (see chart 1) 


determing Ss if program is LOADed or not 


determine s if program is. in transient area or not. 


m cw ow |r 


must be zero 


oO 


- must be zero 


must be zaro 


6 

7  - must be zelro | 
8 primary queueing field addresses TCB 
9 


active program 


10 priviledged| program, 16 registers saved in RB 


11 rescheduable program (re-enterable or reusable) 
12 13 
Qt; | ia ig 
1 RB for IOS 5 no 1OR's 
13 IQE's appended are 12*'s 0 1 - 12 byte IQE's 
. 1 1 ~- 16 byte IQE's 


14 RB exists disjoint from program (RB freed by EXIT routine) 


19° off - WAIT dh single event or all events 
on - WAIT on fewer than the number of events specified, 


FIGURE 2. 


S | nae sR Status Fiold 


’ . 
’ 
é 


7 , 
% , . 
. & ~ 
on ar cn 


: . ~~ "Phe combination of the first four bits in the first flag byte have the 
. ‘Specified definition 4s shown in chart 1 : 


chum 2 


Description. 


PRB, not LOADed, does have minor. 
entries. 


| PRB, not LOADed, doés not have 
| - minor entries. (IDENTIFYed) 


po tf PRB, LOADed, no minor entries. _ | 


SVRB, Type I 
SVRB, Type I 
PRB, LOADed, Minor entry 


GURE 3 


aS4— 


RB Status Field 


OPERATING SYSTEM/360 NAMING CONVENTION 


SUPERVISOR | 
DATA SET UTILITIES 


INPUT/OUTPUT 


MASTER SCHEDULER 
BATCH SCHEDULER 

PROGRAM TEST 

SYSTEM AND SUPPORT UTILITIES 
SYSTEM GENERATOR | 
FORTRAN COMPILER (E) 
FORTRAN COMPILER (H) 


~PL/1 COMPILER (F) 


PL/1 COMPILER (H) 

COBOL COMPILER (E) 

COBOL COMPILER (F) 
SORT/MERGE| 

REPORT PROGRAM GENERATOR 
ASSEMBLER (E) 

ASSEMBLER (F) 

LINKAGE EDITOR 


SYSTEM ENVIRONMENT RECORDING AND RETRY, SERO, SERI 


ENVIRONMENT RECORDING EDIT AND PRINT 


GRAPHIC PROGRAMMING SUPPORT 
TRANSIENT EViC ROUTINES © 
I/O ERROR ROUTINES © 


CLOSE, OPEN [AND RELATED ROUTINES . 


SYSTEM MACRO-INSTRUCTION DEFINITIONS 


LIBRARY SUBROUTINES (FORTRAN) 
LIBRARY SUBROUTINES (COBOL) ~ 
LIBRARY SUBROUTINES (PL/1) 


~85= 


Mics ik} 


Naming Conventinr 


a 


. YME SYSTEM/360 OPERATING SYSTEM 


| O3A 


Or 
OFZ 
LOO 
LOL 
102 
106 


A program check occur 


Completion Codés Excerpts from Form C28-6608 
BSAM CHECK with nd SYNAD routine ot QSAM DCBEROPT specified termination. 
BSAM Write or QSAM|Put record exceeds track length. 

SYNAD routine error following a BSAM CHECK,: 


-_ BDAM OPEN with an invalid DCBMACRF, 


BDAM processing error DCBSQND address outside task boundaries, 


_ BISAM or QISAM OPEN. with an invalid DCBMACRF, 


QISAM processing error and DCB did not contain a SYNAD routine. 


BISAM or QISAM OPEN with an invalid DCBMACRF field. 


BISAM highest level inflex I/O error. 
BISAM OPEN main storage area too Dep to contain the highest level index. 


BISAM OPEN with the DCBMSWA and DCBSMSW ‘Specifying too small an area to” 
—. contain one track of prime data. 


BISAM or QISAM OPEN with no space all cated as the prime area in 1 the DD Card 
or DSCB was modified erroneously. 
BISAM or QISAM OPEN with an invalid buffer specification. 


| QISAM OPEN for load mode with insufficient space allocated or (2) the high level 


indexes crossed volum¢s the DD Cerd SPACE parameter. 
QISAM scan reached the end with no DCBHODAD routine. 


' BISAM or QISAM CLOSE I/O error in updating the Format 2 DSCB, 
' Job Scheduler I/O error in SYS LSYSJOBQE. 


A program check occurred without a recovery routine. X enceties: 


Code Program Interruvtion Cause Code Program Interruption Cause 
1 Operatio 8 Fixed-point overflow 
pe Privileged operation 9 Fixed-point divide 
o Execute A Decimal overflow | 
4. Protection B Decimal divide | 
o Addressing C Exponent overflow | 
6 Specification — D Exponent underflow 
iy Data E Significance 
F Floating-point divide 


A program check occurred in the I/O Supervisor. 
ed in the execution of a Type 1 SVC routine. 

Device not operational. : 

WAIT error from more évents than availablle ECB's, 

POST error from an invalid ECB address. | 

LINK, LOAD, ATTACH pr XCTL error indicated in register 1d; . 

OD Invalid record type found when loading the program. 

OE Invalid address found when loading the program. 

OF I/O error occurred when loading the program, ~ 


-36- 0 


~ 


| Completion Codes 


—— 


I/O error occurrdd with all i/0 recu. est elements in use. 
WAIT error from an invalid ECB address. 

POST error from dn invalid RB address in the ECB end, 
A SYNAD routine attempted to execute an XCTL macro instead of RETURN, 
CPEN failed to find the DSCB or had [/O error. 

Verify the DISP payameter of the DD card. 

CLOSE I/O error in tape positioning or volume disposition. 

BSAM CLOSE I/O error in reading the JFCB. 

CANCEL requested by tne operator. No dump requested. 

Overlay Supervisor found an invalid address in the segment table. 

E of V verification error in label processing. Correct the volume serial 
number in the DD card and re-execuie. 

WAIT specif ied an ECB whose wait bi: was on. 

LOAD error when Option 3 but not 4 iis included. 

OPEN I/O error in reading a Format 3 DSCB. 

CLOSE I/O error in reading the DSCE. . 

BSAM CLOSE I/O error in reading a JDSCB. 

TESTRAN instructions exceeded the limit specified. 

TESTRAN needs an address for ine ‘THST OPEN instruction. 

No DCBEODAD routine available for tie end of a data set. 

An invalid DCB, DEB, IOB or an improper DD Card detected. 

LINK, ATTACH, or XCTL error fror. "only loadable" program or an IDENTIFY 
entry point program specified without Option 4 in the PCP. 

OPEN failed in reading the volume label, the volume could not be mounted on the 
allocated device, -or no volume serial aumber was specified in the SER parameter 
of the DD Card. 

CLOSE I/O error in updating the DSCE. 

BSAM CLOSE I/O error in writing the updated DSCB. 

SEGWT error during execution of an overlay program. 


‘TESTRAN output limit exceeded. 


TESTRAN symbol table and control dictionaries could not be read. 

End of Volume error when the DEBDEBID protection key did not match the TCBPKF 
LINK, LOAD, ATTACH or XCTL used in an overlay program under TESTRAN, | 
OPEN tor a data set on a magnetic tape used for another data set. | 
CLOSE I/O error in reading the JFCB., 

BSAM CLOSE error because the PCP used does not support user labels. 
TESTRAN used without a TEST OPEN instruction. 

TESTRAN used without a DD statement for the unedited data. 

GETMAIN error from an erroneous adcress or length in an inactive program, 

(2) and erroneous address in the macro, or (8) a free area exceeded the 

bounds of the task. 


FREEMAIN error from a free area exzeeding the bounds of the task. 
LINK LOAD, ATTACH, or XCTL error from lack of available storage. 
TMAIN or FREE > MAIN error irom an erroneous address in an inactive programy 
a N I/O error in tape positioning or label processing. 
CLOSE I/O error in writing the end-of-file, 
TESTRAN encountered a machine-check while tracing the program. 


ond of Volume I/O error. in writing the tape mark, POSH LOnIng the tape, or 
reading the label. | 


700 Unit Cneck Status Indication set on. 
— 1705 FREEMAIN issued with L operand and PCP Option 4 not included, | 

706 LINK, LOAD, ATTACH, or XCTL requested an unexecutable program. 

713 OPEN for an unexpired data set created with an EXPDT or RETPD parameter 

— . in tne DD Card = 

714 CLOSE I/O error in tape label processing. 

717 © 3BSAM CLOSE I/O error in tape label processing. 

800 Program or Protection Interruption during an I/O operation. | 

804 GETMAIN with EU or VU mode operand not supported by the PCP in use. 

914, CLOSE functions not supported by the PCP in use. = 
926 Machine Check when TESTRAN attempted to return control to the user program. — 
937 End of Volume functions not supported by the PCP in use. 

A0Q4 GETMAIN error from an erroneous address or length in an inactive program. 
AOS FREE MAIN error when an address and length specification in the release request 
a defined an area overlapping a Iree area. 

JA GETMAIN oz FREEMAIN found the address and length specification in an inactive 

program or released program defined an overlapped free area, =, 
Al3 OPEN failed to find the DD Card specified file sequence number on = | 
Al4 °CLOS® I/O error in the release of unused storage on the DASD as specifiedin .. ~ 
the DD Card. 

A26 TESTRAN covld not return to the problem address specified. 

B04 GETMAIN svecified 2 subpool number greater than 127. 

BY5 PRooeMAIN specified a subpool number greater than 127, 

BOA GETMAIN or FREEMAIN specified a subpool number greater than 127." 

bi4 CLOSE error when STOW was issued. STOW was unable to store, modify, or 

'  Gelete data. The error is indicated in register 15: 

C4 Name already exists in the directory. | 

OC No space is left in the directory. 

10 AI/O error during the search, 
~EOV occurred with no svace available for required functions and no volume 

available for dismounting. 

.OPEN I/G error cr (2) a concatenated data set could not be found. 

Overlay Supervisor detected an invalid record type when loading. 

Oxutour area filled and no secondary quantity SPACE parameter supplied for a DASD. 

Overlay Supervisor detected an invalid address when loading. | 

Outout area filled or (2) 16 Extents already used in a PDS, 

OPEN tailed to find a member name specified ina DD Card or (2) there are 

comilicting or unsupported ae dee. rs in the DCB, a 

Overiay Supervisor detected 2n incorrect length or an I/O error when loading. 

QSAM FEOV I/O error in ae che remaining output buffers. ee | 
BOV or seconcery sovace aiccation I/O error. 

invallia SVC operand, nn = the SVC number. 


a 


a8 | - Completion Code 


